Release management procedures

General rules

The following description is based on best practices applied in myGrid project [available here]:

1. Two weeks before a release preparation, a notification must be made through the FOODIE developer list about the planned code freeze. The actual release date would include additional time for testing, preparation and any last-minute changes, at least a week later.

2. After these 2 weeks, the code freeze is announced.

3. The maintainer (i.e., the person responsible for routine maintenance and processing a release) checks out the entire source tree from the relevant build project.

4. The source tree is branched according to the release version:

• The maintainer, working on the new branch, updates the dependencies by removing the snapshot versions (typically using find and sed).
• Modules which are not updated for this release, are instead pulled in from their previously tagged/deployed versions.
• The maintainer makes sure the code builds and runs locally.
• Then the new poms, and other files such as plugin.xml files, are now committed. The maintainer makes a notes of the commit changes (using VCS logs, automated emails etc).

5. A build is made for this particular version, checking out from the branch. This build forms the first internal release candidate which is distributed for testing.

• At this point any bug-fixes or last minute tweaks are applied to the trunk, and merged across to the release branch.
• After a release is prepared, and packaged, it is handed to the tester users.

6. When a release is ready and sent out, the maintainer does a tag on the branch to mark the release .

7. The build is modified to build from the release tag - this forms a golden master (i.e., a stable-versioned tagged version).

8. The installers are created and uploaded from the golden master built.