Creating a new stable version

At a certain time in the project's development cycle, the configuration manager decides that a feature freeze is necessary to start a new stable version. The exact dates when this will happen are announced on the developers mailing list ahead of the event. When the time has come to freeze the features, a branch will be created as described in this section. From this time on, the stable release will only be changed to make the current features of the software more stable. New features are not introduced to the stable branch but can be developed on the main branch (unstable) in parallel.

When the time has come to create a new stable branch, the following steps have to be performed.

Run through all the steps explaind in Creating a new version. The version number used in this description for the stable version is 0.4. Follow the path for a fresh stable release.
Create a branch off of the tagged version. The branch name is build by appending the word -branch to the major- and minor-release number of the stable release version. For our example, the branch tag for versions 0.4 is rel-0-4-branch. A complete example with all CVS commands can be found in the appendix.
From this moment on, the developers working on versions 0.4.x must make sure, that they checkout or update their sandbox using the tag rel-0-4-branch. This gives them the head revisions of the files on the 0.4 branch. Omitting this tag information will leave them on the main branch. The main branch is reserved for the unstable versions. An example how to keep multiple branches on the same machine is presented in the appendix,
Caution
The developers really have to take care from this point on which version they are modifying in their sandbox. Besides that, it is the developers responsibility to make sure that bug-fixes are also implemented on the main-branch if applicable.

When fixes are applied to the branch, new versions can be created by incrementing the micro-release thus rel-0-4-1, rel-0-4-2 are the next tags on the release branch.

Note

Since CVS does not allow periods inside a tag, we always replace periods (.) with dashes (-) inside a tag.

The following diagram shows the above example on two specifc files. Each node represented by an asterisk is labelled with it's revision number enclosed in parenthesis. If a node has one or more labels attached, then they are enclosed in brackets. Nodes may exist without a tag. Such revisions never went into a release neither stable nor unstable but are valid intermediate steps in the development of the file in question.

Example 2.1. Revisions on the head of a stable branch

The first file is changed rather often between the version tags. All tags are on different revisions of the file.



     *     (1.12) [rel-0-3-8]
     |
     *     (1.13)
     |
     *     (1.14) [rel-0-4]
     |\__________________________
     |                           \
     |                            |
     *     (1.15)                 * (1.14.2.1)  [rel-0-4-1]
     |                            |
     *     (1.16) [rel-0-5-0]     * (1.14.2.2)  [rel-0-4-2]

   [HEAD]                  [rel-0-4-branch]

The second file is not changed at all between the version tags. Nevertheless, all tags are available even though now they are on the same revision 1.2.



     *     (1.2) [rel-0-3-8] [rel-0-4]
     |           [rel-0-4-1] [rel-0-4-2] [rel-0-5-0]
     |\__________________________
     |                           \
     |                            |

   [HEAD]                   [rel-0-4-branch]

Prev:	Home	Next:
Release Management	Up	Announce a new version

Creating a new stable version

Creating a new stable version

Caution

Note