Release Management
Release Planning
The Technical Support Panel (TSP) will decide the major functional requirements of each development iteration which in turn will lead to a release. Each iteration will be as small as possible whilst still adding significant utility to, and building upon, previous releases. Details of how the functionality is to be implemented will be taken at the local level with input from the Technical Lead.
Release Identification
As is increasingly common amongst open source projects, AstroGrid will adopt a stable/unstable branch numbering scheme within the central CVS source tree. Traditionally this means that code under development (unstable) is added to a branch with an odd minor revision number (e.g. 0.1, 2.3 etc) whilst release code (stable) will have an even minor revision number. When the first Beta release of the current iteration is being prepared (i.e. after a functional freeze has been announced – see below), the development branch will be renumbered with an even minor revision number and a new development branch (odd minor revision number) started. Thereafter any bugs found by the beta test programme will be applied to the stable branch and merged into the unstable development branch. In this way development can proceed unhindered by the release process and all lessons learned in the beta test programme included within the on-going development effort. Once the beta testing is complete, the stable branch will be tagged as an Iteration Release.
Release Cycle
The release cycle will follow these stages:
- As the current development iteration draws to a close (or is deliberately closed due to time or other external constraints) a “functionality freeze” or “soft freeze” will be announced. The source tree will be branched and renumbered as detailed above.
- When all functionality is tested and working, a “code freeze” (“hard freeze”) will be announced. Thereafter the only code that will be accepted into the stable branch will be bug fixes.
- With Beta testing complete, the stable branch will be tagged and announced as ready for installation by the wider “early adopter” user community.
- Development on the next iteration will continue in parallel on the new development branch.
Release Building
Building a release should be a simple process, following instructions included in files the CVS tree and by initiating automated build procedures. All code entered into the CVS source tree must be accompanied by test and build scripts, automated wherever possible.
Once built, the release will be internally tested for installation and configuration and where appropriate, test scripts run. The release will then be distributed to beta testers as defined in the [Testing] document.
see
Using Maven to build Tagged Releases
Beta Test Change Management
Feedback from the beta test programme will come in 1 of 2 forms: bugs found and enhancements required. All feedback will be tracked using a change management system and each entry will be assessed for impact, complexity and value. Where the feedback involves additional functionality, it will be assessed by the TSP for possible inclusion in a future iteration. In this way scope creep will be controlled. Where the feedback involves the identification of a bug, a decision will be taken (possible by the Tech Support Group) whether to fix it in the current release or to include the fix in the next iteration. This will largely be determined by the complexity and scope of the bug and it's fix. Full details can be found in the [Change Management] document.
First Customer Ship (FCS)
Eventually the final iteration will be completed and a fully functional AstroGrid system will be ready. Following a beta test programme, AstroGrid V1.0 will be launched. Thereafter it will follow the same procedure as outlined above with the exception that a new development branch will not be started. Support will be provided through the change management process described above, with enhancements being reviewed by the then owners of the AstroGrid project.
--
KeithNoddle - 04 Dec 2002