Release Management for Expresso 5.X

This document is an evoluting document which plans the aspects of release management. Our moto is Release Often, Release Early. This is a challenge as an active community means many commits and each new code commit introduces a new testing cycle. Without proper release management long development cycles result. So here are our release management policies.

Introduction

There following document provides an idea of the release management policy in Jcorporate projects. The first change you'll notice is we now have a release manager. You'll also notice a lot more emphasis on getting stable releases out the door and in maintaining stable releases.

Release Manager

There are two current releases of any project: the "stable" or "release" version, and the "unstable" or "development" version. In addition there is a public CVS system where one can download up-to-the-minute versions of a given project. In a nutshell the project manager or maintainer handles the development tree, and the release manager works on the stable tree.

As of version 5.5 Expresso has a "Release Manager". This committer is David Lloyd who joins Michael Traum as Lead Developer, otherwise known as project manager.

The release manager is in charge of:

As opposed to a project manager, who:

Release Numbers

Version numbers help identify at a high-level what is in a particular release and what has changed since the last release. A "version number" is really just a string of the form:

major-minor-bug-release

A change in the major version number indicates a fundamental change in the architecture of the system, i.e. Expresso 4 to Expresso 5; or a significant number of new features i.e. Expresso 5 to Expresso 6.

A change in the minor version number signifies the addition of new modules, featues and/or minor data model changes, e.g. Expresso 5.0 to Expresso 5.1.

A "bug release" or change in the second decimal indicates is required for security or important bug fixes to maintain a final release for production customers; so it follows the ordered progression: 0.1, 0.2, 0. 3. For example Expresso-5.5.2: would be a second bug fix release of 5.5 final.

Version numbers are also recorded in the CVS repository so that the code tree can be restored to the exact state it was in for a particular release. To translate between a distribution tar file (Expresso-5.2.2.tar.gz) and a CVS tag, just swap '.' for '-' and add the release date. The entire release history of the toolkit is recorded in the tags for the top-level readme.txt file. In the future, Expresso packages should follow this same convention on version numbers.

Transition Rules

The code released (early and often) does not have to be perfect, but it should have an indication of its quality, usually in a version
numbering scheme. The Linux kernel, for example, releases early and often, but odd numbered kernels (2.3, 2.5) are considered "development" quality and only even numbered kernels (2.0, 2.2, 2.4) are considered " production" quality. As of 5.6 we will also follow this convention.

So what distinguishes an early access release from a production release? We follow a specific set of rules for how an project transitions from one state of maturity to the next.

Every release must pass the minimum requirements that it cleanly installs and cleanly upgrades from the previous version. In addition to this the release label implies:

• Nightly Build: This is the default state for the head of the current release branch. We make no guarantees about this code.
• Early Access Releases: All tickets of severity critical have been closed and the distribution has no known installation or upgrade problems. In preparation for a final release CVS is branched to prevent adding new features. This faciliates final testing and minimizes new bugs being incorporated. In addition this release is tested jcorporate's server. Such releases are available for the "Contributors" group to review. Once testing for a week or two the final release announcement would be made to the community at large - essentially then from the user perspective we have no RC's or EA's.
• Production [0, 1, ...] : All tickets of severity medium or greater have been closed, and all documentation is up to date (version history, release notes, new module docs, etc.)..

Mature releases incorporate all the fixes for earlier problems by developing a detailed set of regression tests.

Maintain a Stable Release

Our commitment is to maintaining the last stable release with major bug fixes for our many production users. We can't have new features being added to the released code base as that could prohibit our ability to release quickly - say as required for a security bug.

Only if a bug fix is severe or a security bug will it be included in a stable 5.x.x release. On the whole, security issues, are something that needs to go into the release whether minor or major. It is essential to maintaining a good reputation that we be responsive in making patches to addressing security issues asap. Only the Expresso Lead Developer or Release Manager will check code into the stable release branch. Branching gives us the ability to have 5.5.1, 5.5.2 bug fixes while also continuing with new features in the dev base which is the HEAD of CVS.

More Frequent Releases - "Release Early, Release Often"

The source of this quotations is source of your quotation, "release early, release often") is the Cathedral and the Bazaar, online (http://tinyurl.com/3ald3) and in tree form at Amazon (http://tinyurl.com/25osq).

While a stable release is being prepared, people want/need to check in their new features. CVS HEAD is to the latest dev code to make it easy for committers to move forward with new features.

Our commitment is to the goal of more frequent releases so developers needing a bug fix don't have to wait long for a stable release.

We will run our releases between a few weeks to a few months depending on featue set. I think 4 - 12 weeks is a nice groove.

Extreme/Agile Development

For each development cycle we now define the critical path by only 2-3 iterations (new features) - while these are in development we will accept contributed additional features. Each iteration taking a only few weeks and minimizing risk. The target is this approach will result in a new stable release every 6-8 weeks.

Rapid Application Development Cycle

Providing a fast and effective way to build and deploy a release provides the development team with lots of added value. Defects are best addressed in short “spiral” lifecycles. A reliable efficient release management process makes this possible.

Unit Testing

Unit testing is an integral part of our release management .

Release Process Defined

When a release is determined to be ready for release, the following will occur:

1. Tag Code: We like the current state of things and we'd like to test it out, so we do a build and make it available to the group. The code is tagged with 'expresso5-8-RC1'. NO BRANCH NEEDED YET
2. Branch Code: If the testing goes well and we think only a few things need adjusting, then we branch on that last tag. This way it doesn't matter that people have been changing lots of stuff. What we tested is what we will now adjust for release.
3. Fix Bugs and Release new RC: The 'Release Manager' merges or changes code on the branch to fix bugs identified in the testing. These changes were probably already fixed in the HEAD and just need a merge in, otherwise it gets fixed in both places. The group has to approve each change. But only one person should be doing it.
4. Repeat Step 3 is re-iterated once or twice. NO MORE. Because if it does, it is too unstable and the initial testing was not performed correctly, start over. (Judgement call)
5. Release Final: the branch stays in case of some severe bug that needs addressing before the next release is ready - but it is not kept abreast of any changes! NO WORK PERFORMED HERE. So no work is done on a branch except a few major bugs. The Lead Developer will review the final release, but ultimately up to the release manager to say when to put the download onsite. Please verify that the following are up-to-date before releasing:
   • release notes
   • 3rd party libs download
   • known bug list
   • project summary page reflects correct version
   • documentation onsite is up-to-date with what is in the release
   • put up dated OSS components on site before announcing Expresso new release
6. Downloads put onsite: The final download is first made available to the "Registered" group, preferably on a Thursday or Friday - and an announcment made on the Developers Forum. This spreads some of the downloads over the weekend and otherwise slower time for the server.
7. Release Announcements: The next announcement is made to the listserv (preferably on Monday) and a summary version on the Jcorporate News announcement forum. On the same day, the hosting company is advised to keep a closer eye on the server and usually gives us more system resources temporarily. Tuesday the press release is sent out by Sandra Cann via a press release agency and to many contacts she has collected. Announcements are then also made on Freshmeat, Struts mailing list, Javalobby and other announcement sites.
8. Maintain Stable Release: Only if a bug fix is severe or a security bug will it be included in a stable 5.x.x release. On the whole, security issues, are something that needs to go into the release whether minor or major. It is essential to maintaining a good reputation that we be responsive in making patches to addressing security issues asap. Only the Expresso Lead Developer or Release Manager will check code into the stable release branch.

Once testing for a week or two the final release announcement would be made to the community at large - essentially then from their perspective we have no RC's or EA's.

What Releases are Supported?

Expresso's most current "stable" release is what is supported. Old releases are not supported. Thus, we encourage your policy to embrace the adoption of stable releases into your software development and policies.

Transparent Project

If you keep the fruits of your project to yourself, except at final release time, you are guaranteeing that the only people who can
contribute and aid your efforts are the people on your internal development team. Open source code alone does not make a project a
useful and successful effort. It is the creation of a community of interest, many people from many different organizations, all with an interest in making the software better, that makes a successful project. Wide communities of interest" future proof" open source software and provide a guarantee of ongoing support and development. Small ones are dangerously transient and
dependent on the caprices of a few programmers or organizations.

Road Map Document

Our community too often asks me what our direction is - so the roadmap document is essential to let our users know. This document is important as the more transparent a project is the greater the chance that somebody else will want to participate. Exposing the design process while it won't get somebody to join early will documents that we are open to outside participation which increases the possibility that we will get others to join the development effort :)

The roadmap outlines the direction that is planned for the next few iterations. This document is a guideline for the developers to determine when to tag the code in preparation for the release process. This is a critical element to our community building.

Conclusion

An open process, with "release early, release often" and "open CVS archive" as transparency mechanisms, helps build that shared community of interest, by letting everyone in the door.

If you have other suggestions for improving the release management of Jcorporate's projects please let us know.

Copyright © 2002-2004 Jcorporate Ltd. All rights reserved. Copyright Privacy

Last Modified: 13-May-2004