Release Strategy

[Ted Husted]

Just a suggestion:

Right now, Spring.net is using the "release candidate" strategy, where a single release number (say, 0.6) is used for a series of betas and release candidates, which may culminate in a final release, again under the same release number.

Another strategy, used by the Apache HTTPD team and others, is to give each release an immutable milestone number (say, 0.6.3), and then assign a quality grade to the release, which may change over time.

So, a 0.6.3 release may start out as a beta, and if there is positive feedback from the community, a few week later, it may be upgraded to "stable" or "general availability" grade.

And, if, after that, an issue is found a few months later, the quality grade assigned to release can also be downgraded.

I've worked in projects under both systems, and I do find that the "immutable milestone" strategy works quite well in practice.

If nothing else, it eliminates having to make yet another release after a "final" release candidate in which, by definition, nothing should change.

HTH, Ted.

[Mark Pollack]

Hi,

Sorry to see this so late - better hit that 'unanswered posts' more often :).

I picked the release candidate strategy simply because that was the strategy used by Spring.Java but we don't have to stick to that. This may make sense also because of the embedding of the number inside the assembly. I don't like the fact right now that I can't tell rc2 from rc3 by looking at the assembly. With the scheme you mention that would also be solved but I was hoping to have 0.x.0 by definition be considered a "stable" release. I'll cross post to the dev list to see what other people say. Are there any docs on this strategy? I've tried to stick with the scheme of the portable runtime for other products I work on. APR versioning (http://apr.apache.org/versioning.html)

- Mark

(edited to clean up my terrible spelling/typos...)

[Ted Husted]

I don't know that it's documented separately anywhere. The strategy is implicit to the Apache HTTPD release guidelines.

* http://httpd.apache.org/dev/release.html

The central ideas are that the quality of the release is driven by feedback from the community, ongoing development cannot pause whlie we obtain feedback, and our judgment of the quality may change over time. For example, if a security issue is found, we would want to downgrade the release quality, regardless of how well the rest of it works.

Several other Apache projects use the same strategy, including Tomcat and Struts [http://struts.apache.org/releases.html].

The procedure boils down to:

* Tag the release (x.x.n)
* Roll and post the release to a test directory
* Announce to the mailing list (always Dev, sometimes User) that the release is available for testing
* After a suitable period, call for a vote on the release quality
* If appropriate, make the release available on the main distribution site
* If appropriate, call for other votes to upgrade or downgrade the release quality.

The scheme works well with SourceForge. You just edit the description to include ALPHA, BETA, GA, STABLE, or whatever.

HTH, Ted.