Calendar:Branch Model
Right now we are attempting to develop two projects (Sunbird & Lightning), and we have concerns about how we want to do handle various stable/unstable branches of Gecko. Some goals include:
- have a stable platform to ship Sunbird builds against
- ship a Lightning that works with Thunderbird 1.5 (ie the Gecko 1.8 stable branch)
- not be unduly slowed down or hindered by whatever development model we choose
The standard model of development in a world with these goals would be to do what the rest of Gecko does: do all core development on the trunk, and simultaneously land all appropriate checkins on the branch. A key difference between us and the rest of Gecko is that there is still a tremendous amount of work to be done in the calendaring code that needs to work against the stable 1.8 branch.
Another possible model would be to tweak the 1.8 branch client.mk to, by default, pull the code in mozilla/calendar from the CVS HEAD instead of the branch. This helps us avoid all the extra checkin work, but has some disadvantages as well. Part of this has to do with calendar's dependence on mozilla/storage and mozilla/extensions/webdav. Neither of these things are turned by default in the 1.8 branches, meaning that Lightning will need to ship its own.
A third model has been suggested, which would be to do main development on the trunk, and do a big code drop to the branch every so often.
Here is the set of (known) divergences that have already happened, will happen, or are likely to happen that we care about in platform areas:
Have happened:
- UUID generator code has landed on the trunk only
- minor storage API change
Will happen:
- WebDAV & storage code will be part of default builds on trunk, branch status unclear
- There will probably have to be some WebDAV code changes to support new CalDAV features
Might happen:
- There are http channel changes (base channel) happening on the trunk that might require WebDAV code changes there
[MORE TO COME]