Each release gets a permanent release branch named buildbot-X.Y.Z. This branch is created just before tagging the first release candidate. All distribution packages are created from this branch, with any changes cherry-picked between the branch and master. Do not try to do fancy things with merges!

Each distribution package is created by first tagging the release branch with a tag of the form vX.Y.Zblah} (note: no dash between the version number and the suffix). Thus, the tag specifies exactly the revision from which that distribution package was created (and, in fact, the version numbers in the distribution won't come out right if this practice is not followed).

The commit on master *after* the release branch begins is tagged with the next version and -pre, e.g., v0.8.3-pre. This means that builds from trunk will have versions v0.8.3-pre-NN-HHHHHH. If plans change and the expected next release version changes (e.g., to 0.9.0 or, dare I imagine it, 1.0.0?), then just re-tag the master at that time with a new -pre tag.

Release branches are left open forever in case a security release needs to be made. In that case, the relevant fix is committed to the branch, a new tag is made (with a pN suffix), and a distribution package created. Note that, aside from critical security patches, we do not support any release but the most recent. Bugfixes for a given release are also made on the release branches, particularly for bugs that break significant functionality. These are typically released as pN release, shortly after the main release.

Last modified 7 years ago Last modified on Nov 21, 2012, 4:41:00 AM