Release process

Introduction

When releasing a new version of a component, certain things need to be in order:

• Content: the content is known
• Stability: version 1.1.1 stays 1.1.1 over time (only one 1.1.1 version)
• Continuity: work doesn't stop on the component during the test/release phases

The process described here should take the points above into account.

Configuration management

Release branches

Most of the work done in order to make a release happens in our source control system: Subversion.

Branching strategy describes how development branches (a.k.a feature branches) are used. However, in order to support continuity (see introduction), a new class of branches is introduced: release branches. The picture below shows how they work:

The blue branch is a development branch. The red branch is a release branch.

All release branches are made from trunk. All releases (tags) are made from release branches. Bug fixing are done on release branches and the changes must be merged back to trunk. New bug fix releases are made from release branches.

Only when new features are introduced in the component a new release branch should be made.

All changes made to trunk (merges) should be reviewed.

Version numbering

All component version numbers should be formatted like:

x.y.z, where:

x = major version. Increased if major changes are introduced.

y = minor version. Increased if minor changes are introduced.

z = build version. Increased with every release from a given release branch.

NB! for trunk, z is always 0.

The picture above shows the version numbers used on branch and tags names (large fonts) as well as the pom files (small fonts). Release script

Process

Overall test/release cycle

The picture above shows the overall release process. This can also be described as follows (steps 1-3 are not part of the picture above):

1. Do work on a component on a development branch
2. Merge to trunk
3. Make a release branch
4. Make a release (tag) and build it using Hudson
5. Deploy on a test environment
6. Perform test
7. If an error is found, fix it on release branch, merge to trunk and repeat steps 4-6.
8. No errors are found. Continue on QA and prod.
9. If an error is found, repeat steps 4-8.