Planning of future releases
General plans/Guidelines
General guidelines for handling release branches
To keep things organized every stable release (1.0, 1.2 etc) should have its own branch within CS/branches/release/ directory. The branch is created by project administrators (and if you are the one to do it, read the HowToCreateReleaseBranch).
As the branch is intended to be for a stable release there are some guidelines to make it a bit more stable:
- Be careful on integration. Experimental changes should not be put in the release-branch.
- Any branch-specific changes as well as merges from trunk should be written down in a history<version>.txt (f.ex. history10.txt) file in docs/ subdirectory.
- Fixes on the branch should in their history and commit message contain a reference to a trac ticket. Tickets should be refered to as "trac #123" where 123 is replaced by ticket id.
- Merges from trunk to a branch should contain the merged revision(s) in the commit message as rXXXXX:YYYYY - if you copy the range from the command line and prefix it with an 'r' you can't do much wrong.
- Make sure that jam check builds cleanly and that all tests pass.
- After the stable release only critical bug-fixes (not needing API modifications) are allowed into the branch.
Version numbers
CS version numbering is M.X.Y<addon> where M is major version, X is release, Y maintenance release and <addon> any extra tags such as rc1 etc.
Examples:
- 1.0RC1 - First release candidate of what is to become release 1.0.0
- 1.3 - Development version (trunk) after release of 1.2.0 but before 1.4.0
- 1.2.3 - Third maintenance of stable 1.2 release
A maintenance release should only contain bugfixes compared to the stable release. Stable releases should be API compatible with lower versions, breaking changes should only be introduced in major versions.
Perhaps we'll also adopt code names for stable versions. Not decided yet.
Release schedule
There should be a stable release every 6 months. A major version should be released every year where possible. Maintainance releases should be pushed out as needed. Possibly gathering multiple fixes into one.
The Release dates aren't fixed, but instead there will be a certain featureset that should be completed to make up a certain release. These will be organised via trac and shifted to later versions if needed.
