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.
One of the Endefr team members will be assigned as the release manager. He is responsible for:
version.properties;The location and format of the release notes and the change history are described in the document about the documentation of releases.
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 version.properties.
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 version.properties 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.
The tagging and branching for which the release manager is responsible is described in the CVS structure.
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.
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.
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.