Release Engineering
From MediaWiki
We adopt a Release Engineering process closely based as FreeBSD project.
Main policy
- Development is done primarily in the trunk;
- Isolate feature sets on a separate branches if necessary;
- Backmerge often, if we have parallel branches;
- Release often.
Release Process in a nutshell
- When we believe we need have a reasonable version, we may create a branch for trunk.
- Eventually some small adjustments are necessary to a certain branch before creating a tag from it;
- We create a tag from the latest revision of a branch;
- We generate binary packages, etc from the tag;
- A release branch or tag must be created from trunk, always. A release branch or tag must include all subprojects, directly, indirectly related or even unrelated.
Example
- The tag that Release Engineering assigned for the 0.1 release was TAG-0.0.1-RELEASE. Development continue on the trunk as usual;
- At the time of each release, a branch is created, such as BRANCH-0.1. Although the source files named by TAG-0.0.1-RELEASE will never change, those on BRANCH-0.1 can, by the adoption of changes from trunk such as fixes for security and other bugs;
Some considerations
- I don't believe we need multiple parallel branches but we are prepared to develop in parallel and backmerge often;
- A branch will rarely change after its own release. In particular in the early stages of development, the effort spent on configuration management would be better directed to work on the trunk.
- Configuration management is a key factor which makes our lives easier or may kill us. We need to learn with others.
See also
- FreeBSD's Release Engineering process
- Release Scheduling In The Past shows some lessons FreeBSD team learned.
- Version Control for Multiple Agile Teams shows one possible approach to manage multiple parallel branches. Be warned that it's only one possible approach i.e: there are other possible ways do do the same thing, providing even more flexibility.
RichardGomes 15:22, 10 February 2008 (UTC)
