Release Cycle

At any time there are two official versions of Aqsis available for use, the stable version, and the development version. They are differentiated by the version numbering, and the release procedure. The numbering system is described below, the example illustrates the version 1.4.0.

When the development reaches a point where a new stable release is relevant, the following cycle is used to complete the release. The cycle is designed to minimize the possibility of a failed release, and allow a wide audience to preview and check the release before it becomes official. The cycle includes sufficient lockdown time (time when the SVN repository is locked to any new additional functionality) to ensure that the functionality agreed for release gets plenty of attention during the final stages of development.

• The final set of functionality for the new release is agreed upon between the developers involved.
• SVN enters lockdown, no new functionality beyond that agreed is allowed into the trunk.
• New builds of 1.x.0 (where x is odd, indicating a development release) will be made available for download daily.
• Duration 3-4 weeks

• The agreed new functionality is functionally complete, no changes to the mode of operation of new features from this point.
• SVN is open only to very minor implementation changes (that do not affect the functional implementation), and bug fixes.
• Users can reliably start testing the new features, safe in the knowledge that anything produced will be valid at release.
• New builds of 1.x.0 (where x is odd, indicating a development release) will be made available for download daily.
• Duration 3-4 weeks

• The agreed new functionality is complete.
• SVN is open only to bug fixes.
• New builds of 1.x.0 (where x is odd, indicating a development release) will be made available for download daily.
• Duration 2-3 weeks

• A new 1.x.0 (where x is even, equal to the previous stable release +2) is made available.
• The development build min number is incremented by 2.
• SVN is reopened to new functionality.

The release procedure for a patch release, that is a release with only a build version increment i.e. from 1.4 to 1.4.1, has to be necessarily much more lightweight than the major release procedure. It is important to be able to get out bug fix releases in a timely manner in order to address real user issues. The major release procedure potentially lasts for many months, the patch procedure should last only for a very small number of days or weeks, ideally less than 2 weeks.

The conditions for a patch release are fairly flexible, and the decision to make a patch release should be discussed and agreed amongst the developers. The general criteria for releasing should include the fixing of major bugs that have been reported by users in live situations, and the fixing/improvement of features by developers that are likely to impact real world usage.

The sort of changes that should be considered for back-porting to a patch release from the trunk include the following.

1. Any bug fixes to existing functionality.
2. Performance and operational improvements to existing functionality.
3. Improvements to the deliverable packages.

Changes that should not be considered for inclusion into a patch release include the following.

1. New features.
2. Operational changes to existing features that could potentially break existing content.
3. Removal of any existing functionality.
4. Anything that's not in the trunk.

Once the release conditions and contents have been agreed, the release procedure follows a single phase release structure. The developers follow simple, lightweight set of steps defined here, and the release should be available for download within a few days.

During development, releases will be made available periodically based on the work in progress code in the SVN trunk. These releases will always be tagged with the SVN repository revision number, as the rel number doesn't apply to development releases. This allows a user to accurately identify the version they are using when reporting bugs. For example, a development release of 1.3.0 might report 1.3.0 (revision 1839).