[Opensim-dev] Release Strategy

[jradford]

On Thu, 30 Apr 2009 19:19:32 +0100, Justin Clark-Casey
<jjustincc at googlemail.com> wrote:
> diva at metaverseink.com 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!