BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Tzfile/Europe/Stockholm
X-LIC-LOCATION:Europe/Stockholm
BEGIN:STANDARD
TZNAME:CET
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-2SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
DTSTART:19700329T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:20081215T132542Z-11349-101-1-0@zimba.it.su.se
DTSTAMP:20081217T081520Z
DTSTART;TZID=/softwarestudio.org/Tzfile/Europe/Stockholm:20081221T220000
DTEND;TZID=/softwarestudio.org/Tzfile/Europe/Stockholm:20081222T000000
SEQUENCE:4
SUMMARY:Discuss module version management\, how to handle multiple 
 versions of a module?
LOCATION:#lunar or #lunar-dev on freenode
CLASS:PUBLIC
TRANSP:OPAQUE
ORGANIZER;CN=Stefan Wold:MAILTO:ratler@lunar-linux.org
CREATED:20081215T134216
LAST-MODIFIED:20081217T081248
DESCRIPTION:Invitation to discuss version management in lunar.\n\nA few 
 questions to get you all started:\n* Do we want to continue renaming 
 modules when a new major release is out or can we do it differently? If 
 so what ideas do we have around multiple versions?\n* How do we want 
 version management to work in the future?\n* Pros and cons with our 
 current way to handle versions\n* How much work are we ready to put into 
 the lunar tools if we change the way it's working today?\n\nWell you get 
 idea. All developers are welcome to participate in the meeting. I know 
 it's just before christmas but after a brief discussion in #lunar it 
 seemed necessary to do this as quickly as possible.
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;LANGUAGE=en:MAILTO:lunar-dev@lunar-linux.org
END:VEVENT
END:VCALENDAR