The structure of the CVS is designed to support the following requirements:
The tag and branch names of CVS cannot contain certain characters. This is problematic with version numbers as they contain dots which are not allowed. For CVS names the dots in version numbers will be replaced with underscores.
To refer to the latest code of a branch the term tip is used. Although the term head is used
often, it will not be used by the Endefr project. The term head is used to refer to the initial branch of
the repository, HEAD.
After the project infrastructure and development documentation have been created, but before the actual work on the project is started the following actions will be performed:
Empty;Br1_01, based on the tag
Empty.Before building a (pre)release the release manager will tag the CVS to make sure that the code from which the (pre)release was built can be found.
The name for tags is composed of the following parts. The version parts are formatted the same as in a version number:
Rel;When a new version (or a new architecture, which also means a new first version: version n.01) needs to be created, the team has to decide on what code to base the new version. A new version can be based on any (pre)release or the empty project.
For each new version a branch is created so the team can work on different versions in parallel. The branch for the new version is created by branching from a (pre)release tag. It is not allowed to create branches for versions based on non-release tags or the tip of another branch.
The name for branches is composed of the following parts. The version parts are formatted the same as in a version number:
Br;Below are a couple of examples of what happens to the CVS when a new version is created. They also show the effects of the release management policy on the CVS.
After two alpha and one beta prereleases, version 1.01.00 has reached gamma status and will be released.
The release manager creates tag Rel1_01_00. After building and releasing the project, he changes the version in
version.properties to 1.01.01b01-dev. This is a beta version because the team has
decided not to use an alpha status for revisions.
The users are enthousiastic about the project and feature requests pour in. The set of features are a
significant addition of functionality, so it is better to start a new version, 1.02, instead of extending version
1.01. The release manager creates a branch, Br1_02, for the new version based on the release of
version 1.01.00. He changes the version number in version.properties to
1.02.00a01-dev.
As the team works on version 1.02 a bug report comes for version 1.01 in. As version 1.02 is not
production-ready yet, it is better to create a revision of version 1.01 for a release with the bug fix. A
developer switches his workspace to the branch Br1_01. He makes the changes and when he is done the
release manager checks the quality. After quality assurance the changes are also applied to the version 1.02
branch because this branch was based on version 1.01.00.
Before moving version 1.01.01 to the gamma status the team wants users to test the changes, so they
release version 1.01.01b01. The release manager creates tag Rel1_01_01b01, and changes the
version in version.properties to 1.01.01b02-dev.
A lot of progress is being made on version 1.02. The team wants to get an alpha prerelease out to get
early feedback on the new features and on how they are implemented. The release manager creates tag
Rel1_02_00a01, and changes the version in version.properties to
1.02.00a02-dev.
The feedback from the alpha prerelease of version 1.02 indicates that the users like the new features, but find them too cumbersome to use. After discussion between the developers and the users, the developers decide that it is best to start with a new API instead of extending and/or modifying the API of version 1.01.
In this case it is decided that it is easer to start from scratch than to refactor the code of
version 1.01. The release manager creates a branch, Br2_01, based on the empty project for the
new architecture. In this new branch, he changes the version in version.properties to
2.01.00a01-dev.
As the Br1_02 branch is no longer active, the release manager changes the version in
version.properties to 1.02.00a02__CLOSED__.
See the list of active CVS branches.
Prototype branches are used for experimental code. By putting this code in a separate branch multiple developers can work on it, and they can do so without interfering with the production code.
The name of prototype branches is composed of:
Prot;Here are a couple of prototype branch names:
A prototype branch can be created from a tag or from the tip of another branch. The version in version.properties must be changed to a version number composed of:
.prot-;Here are the prototype version numbers corresponding to the prototype branch names above:
When a prototype branch becomes inactive the string __CLOSED__ is appended to the version number
in version.properties.
The CVS structure as described above has one major issue, the project infrastructure and development documentation are duplicated in multiple branches. This could lead to inconsistencies between branches.
To prevent inconsistencies the project infrastructure and the development documentation will be maintained in the branch with the highest version number. The changes to the project infrastructure will be applied to older branches only if needed to ensure correct operation.