Differences between revisions 4 and 5
Revision 4 as of 2004-12-04 07:38:58
Size: 4436
Editor: dsl093-180-161
Revision 5 as of 2009-09-20 22:02:37
Size: 4438
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 44: Line 44:
The news on [http://jakarta.apache.org/] need to be updated as well, but I have never done so. Someone else did, do not know who... The news on [[http://jakarta.apache.org/]] need to be updated as well, but I have never done so. Someone else did, do not know who...

Steps towards a new release

This describes my experience as a release manager what is to be done to roll out a release. I am almost sure I forgot many important things. People who know better should just add their stuff. (OZ)

Assure people want a release

First of all you need to be sure committers agree that the time is right for a new release. You can either do this informally or with a formal vote. If you don't vote now you will have to have a vote in a subsequent step of this process. Vote results must be cc'ed to the PMC as they are formally responsible for the release. Such a result message such summarize if the vote passed, who voted for what and contain a link to the vote thread in the archives. If you do a vote add a date when the vote will be ended. A week is default within Jakarta.

Settle on a release date and type

After you have assured committers want a release you have to settle on a release data and what kind of release it is going to be. Read more on the types of a release at WhatDoesAlphaBetaRcFinalMean. If this release will be the first of a complete release cycle it might be good if you have a release plan that says how many releases there will be before the final one and when they are to be expected. To be on the save side assure committers agree to this overall plan as well.

Call out a feature freeze (if applicable)

If the release to be done is the first in a release cycle, i.e. a first alpha or beta, you will have to make sure people agree on a date for a feature freeze. After this date no new features go into the scheduled release. It might be a good idea to fix the time between the feature freeze and the actual release even now, but to me this is a matte of taste.


When the date for the feature freeze is there, freeze the state the sources in order no commits in the meantime mix with this well defined state. You can either set a tag or simply do not more cvs updates to your local version then. Maybe a tag is better so others can refer to this for testing as well.

If this is the first release in a full cycle you might consider creating a release branch now. If you do not do it now you will have to create it later in this process. A release branch is important to avoid mixing new features with fixes that you apply to the release. Be sure careful not to delete the release branch after the final release as maintenance releases might be necessary after that.

Update release notes and set the right version in build.xml.


Run the test suite and let others report if they are satisfied with what is there. If not let them fix this even before the release.


After tests have passed actaully make the release as described here BuildSignUploadDeploy.

Sane Checks

Before actually announcing or maybe even before updating download pages you should ask committers to download and check distributions. Most of the time I forgot to set permissions, missed an important distribution part or messed up anything else. Notice, this is no bug fixing!


After you have the impression the distributions are ok, send an announcement mail to Slide's development and user lists and to the Jakarta announcement, pmc and general lists. Be sure to be subscribed to all those lists as otherwise your post might not come through.

The news on http://jakarta.apache.org/ need to be updated as well, but I have never done so. Someone else did, do not know who...

Additionally, the fine folks at http://theserverside.com/ have requested that someone from the Slide community post announcements for final releases on their site.

Announcement email template:

[ANNOUNCE] Release of Slide {version}

The Jakarta Slide community is pleased to announce the release of Slide
{version}. This is a bug fix release and brings Slide closer to a final
{version} release. Feedback is greatly appreciated, especially in the form of
bug reports.

You can download Slide {version} from:

Release notes are at:

The Slide project page is:

{Your Name}
(on behalf of the Jakarta Slide community)

StepsToRelease (last edited 2009-09-20 22:02:37 by localhost)