Announcing ri_cal version 0.8.8
a new implementation of RFC2445 in Ruby
A new Ruby implementation of RFC2445 iCalendar.
The existing Ruby iCalendar libraries (e.g. icalendar, vpim) provide
for parsing and generating icalendar files,
but do not support important things like enumerating occurrences of
repeating events.
This is a clean-slate implementation of RFC2445.
A Google group for discussion of this library has been set up
http://groups.google.com/group/rical_gem
Changes:
=== v0.8.8 2011-02-13
Regenerate gemspec for version 0.8.8
Version bump to 0.8.8
fix x property access
change rakefile to use ad_agency
=== v0.8.7 2010-04-16
Regenerated gemspec for version 0.8.7
update history
Version bump to 0.8.7
fix tickets #29-supress x-rical-tzsource when not relevant
=== v0.8.6 2010-04-15
Regenerated gemspec for version 0.8.6
update history prior to release
Version bump to 0.8.6
fix tzinfo timezone export
force change managment datetimes to zulu time
added ZuluDateTime property for use by change management properties
parked a spec
Convert to jeweler
Version bump to 0.8.5
remove unneeeded Date#to_time and DateTime#to_time methods
remove inf loop spec temporarily
Working on a bug where a recurrence rule with simple by-parts
caused an infinite loop See spec/ri_cal/inf_loop_spec
Although the reported bug is fixed there is still work to do
because giving an event a dtstart
not within the recurrence rule produces incorrect output.
1) 'an event with unneeded by parts with a dtstart outside the
recurrence rule should enumerate 10 events first July 12, 1940, July
13, 1940, July 13, 1941 when count is 3’ FAILED
expected: [“1940-07-12”, “1940-07-13”, “1941-07-13”],
got: [“1940-07-12”, “1940-07-13”, “1941-07-12”] (using ==)
I'm going to push this to github, but not release a new gem
version until I can fix this latter bug.
fixed infinite loop bug for reported case
website and gemspec
Fixed Ticket #26, failing with date values for event dtstart and
dtend
updated website
=== v0.8.4 2009-09-18
fixed gemspec problem
=== v0.8.3 2009-09-18
prepared to publish
refactored occurrence incrementers
checkpoint
changed ri_cal.rb to autoload
changed ri_cal.rb to autoload
=== v0.8.2 2009-09-05
another attempt to trigger github to rebuild
fixed gem version so github should now build
Fixes
http://rick_denatale.lighthouseapp.com/projects/30941/tickets/23
initialization_methodsrb-syntax Fixes
http://rick_denatale.lighthouseapp.com/projects/30941/tickets/24
need-to-handle-empty-property-values
fixed ticket #23
adopted patch from ebigart
Support properties with no value (e.g. ‘LOCATION;LANGUAGE=en-US:’
gets generated using Outlook)
=== v0.8.1 2009-08-18
Fixes
http://rick_denatale.lighthouseapp.com/projects/30941/tickets/21
exception-when-count-option-used-to-enumerate-non-recurring-event
=== v0.8.0 2009-08-11
Minor Version Bump - There is a small potentially breaking change
see section on treatment of X-properties below * Unknown Components
Starting with version 0.8.0 RiCal will parse calendars and
components which contain nonstandard components.
For example, there was a short-lived proposal to extend RFC2445
with a new VVENUE component which would hold structured information
about the location of an event. This proposal was never accepted and
was withdrawn, but there is icalendar data in the wild which contains
VVENUE components.
Prior to version 0.8.0, RiCal would raise an exception if unknown
component types were encountered. Starting with version 0.8.0 RiCal
will ‘parse’ such components and create instances of NonStandard
component to represent them. Since the actual format of unknown
components is not known by RiCal, the NonStandard component will
simply save the data lines between the BEGIN:xxx and END:xxx lines,
(where xxx is the non-standard component name, e.g. VVENUE). If the
calendar is re-exported the original lines will be replayed.
* Change to treatment of X-properties
RFC2445 allows 'non-standard' or experimental properties which
property-names beginning with X. RiCal always supported parsing
these.
The standard properties are specified as to how many times they
can occur within a particular component. For singly occurring
properties RiCal returns a single property object, while for
properties which can occur multiple times RiCal returns an array of
property objects.
While implementing NonStandard properties, I realized that
X-properties were being assumed to be singly occurring. But this isn’t
necessarily true. So starting with 0.8.0 the X-properties are
represented by an array of property objects.
THIS MAY BREAK SOME APPLICATIONS, but the adaptation should be
easy.
- No changes other than a version number bump. github seems to
have failed to notice the commit of v0.7.6
and didn’t build the gem. Hopefully it will notice this one.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale