On Thu, 30 Apr 2009 19:19:32 +0100, Justin Clark-Casey <[email protected]> wrote: > [email protected] wrote: >> Do I hear a volunteer release coordinator? Stefan doesn't have time, so >> someone has to step up. >> >> :-) > > I think you probably need to be a core developer to do this :) > > > However, it will require a strong personality who is prepared to revert > code in the rc period, and I think that this > process would require the consent of all the core developers.
I'll throw in my 2 cents here and tell you how we (the libomv) team do releases: Primary development happens in our trunk branch, patches submitted by users are generally applied here as well. We have a loose idea of the features major and minor we want to add to the next version of the library. Once a good portion of these features are implemented we'll create a -dev branch from trunk, this will become the next major release. As time goes on and fixes are made, these fixes are merged from trunk into the -dev branch appropriate for the fixes To ease end user pain we attempt to maintain API compatibility between major versions, for example our 0.6 release series from 0.6.0.0 to 0.6.9.9 (if we ever got there) should all be API compatible, no breaking changes. We tag our releases from -dev branches, any bug fixes to a release are merged to that specific dev branch and when enough changes are collected that warrant a point release one is tagged incrementing the version minor. We generally maintain previous releases by backporting (via merges from trunk) bug fixes for as long as possible. "As long as possible" depends on a couple things: 1) how long and how stable a newer release has been published, and 2) how painful it becomes to maintain previous branches. This varies from release to release, but generally speaking about the time the next major release comes out the previous release is very stable and requires much less maintenance. This is becoming increasingly so due to the fact the library is mostly feature complete and the API remains stable. When a developer proposes an experimental feature they will generally create a branch from trunk and implement and test until they are satisfied with the work. That developer then merges the changes back into trunk and depending on if it has breaking changes or not, it can be merged from trunk to the -dev branch for the appropriate release. So in our world the svn structure looks something like this: /trunk /branches/0.5-dev /branches/0.6-dev /branches/0.7-dev /branches/jradford-experimental-messagesystem /tags/0.6.0 .. /tags/0.6.2 In this tree 0.6 is our current release, 0.7 is our next major release pending, and 0.5 is a release nobody really uses anymore. Any tagged release in the 0.6 series should be API compatible and a drop-in dll replacement. As far as a strong personality, whoever is doing your releases simple doesn't merge changes from trunk to the appropriate dev branch unless its a complete implementation and proper testing has been done. For the most part occasionally prodding a developer to complete a feature is all it takes to get the necessary fixes committed to trunk so that developers feature can get merged into a dev branch for the next release. A couple other things to consider to make life easier for your release person: Smaller specific commits are better, they cause fewer merge conflicts and of course if a reverse merge is required (backing out a commit) you're not having to edit a bunch of code. This is the process we've been using for over a year now and it seems to work well so maybe some of what has worked for us can work for you guys. Lastly, no matter how well you do releases, the bulk of your users are going to use trunk and complain when its broken. -- Jim !DSPAM:370,49f9f9b760474213649381! _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
