Release management

To prevent different artifacts from being distributed with the same (pre)release version number, Endefr uses a strict release management policy. This policy cannot prevent multiple artifacts with the same (pre)release version number from existing, e.g. renaming a file is easy. But this policy prevents the Endefr team from causing the confusion, and this policy makes it easy for users to determine whether they have an official or unofficial (pre)release.

Release manager

One of the Endefr team members will be assigned as the release manager. He is responsible for:

Release notes and change history

The location and format of the release notes and the change history are described in the document about the documentation of releases.

Version numbers

The version numbering scheme aids in distinguishing between official and unofficial (pre)releases. Official (pre)releases have neither a −dev nor a −dist suffix in their version numbers.

In the CVS an official (pre)release version number is never present in Official (pre)release version numbers only exist temporarily in the check out of the release manager. After building the (pre)release the release manager changes the version number in the next development version number and commits the changes. Below is an example of what happens to the version number when the first official prerelease of a project, 1.01.00a01, is released:

Here is an example showing the transition from beta to gamma (transition from alpha to beta is similar). The release manager has decided that the code for beta 3 is production-ready, and the team has agreed upon a transition to gamma status. There will be no beta 3 prerelease, but instead the code is promoted to the gamma status:

As you can see the version tag is set on a revision which does not contain the same version as the tag. This prevents that when the tag is checked out and the project is built, that the build artifacts have an official (pre)release version number.

Tagging and branching

The tagging and branching for which the release manager is responsible is described in the CVS structure.

Commit silence

After the Endefr team has agreed upon a (pre)release, a period of commit silence is started. During this period nobody, except the release manager, is allowed to make changes to the CVS repository, unless specifically asked to do so by the release manager.

The release manager will not start the release procedure before all comitters have indicated they are aware of the commit silence. To ensure the delay between agreement upon a (pre)release and the start of the release procedure is as short as possible, the request to confirm the commit silence is sent to the endefr-development list and the committers themselves.

Not responding to the commit silence request means (temporary) removal from the team, to ensure that the person which does not respond does not interfere with the work of the release manager.

When the release manager is done, he will send a message to the endefr-development list indicating that the commit silence period has ended.

Verifying releases

After building the (pre)release and making it available for download, the release manager will publish the MD5 sums of the archives which were generated during the build at the releases page of the project. With these MD5 sums users can verify whether an artifact is an official (pre)release, or an unofficial (pre)release with a official version number.

Daily builds

For people who don't have access to the CVS repository, the Endefr project also provides daily builds. For each active, non-prototype branch a daily job will attempt to build the branch. If the build is successful the last successful build of the branch is removed and the new one is added.

The time at which the daily-build job is run is not fixed, and may change during the life of the project.

No tag will be created for the daily builds, so it is not possible to retrieve the sources on which the daily builds were based.

The project page of Endefr at