Versions
This page documents the proposal for a version numbering scheme for all ProgClub projects. This versioning system will be designed and documented here first and implemented for all ProgClub projects when it is ready.
Version numbers will be in the format Major.Minor.Revision as described here. The versioning processes described in this document are to be implemented by the pcsvnrelease script.
Status
This document is a work in progress.
Components
Major version
The major version is an integer starting from '0' (for the initial development), incremented to '1' for the first "production quality" release, and thereafter incremented to '2', '3', etc., as successive major versions are released.
If a new release is going to be incompatible with a previous release then the major version number should definitely be incremented. The major version number can be incremented even if a release is compatible with a previous major version release, and it might be incremented to indicate that significant new functionality has been added, i.e. for "political" or "marketing" reasons.
Minor version
The minor version is an integer starting from '0' (except for the major version '0' where the first minor version is '1'). The minor version is incremented so that previous minor versions can go into "maintenance" mode. Generally minor versions are incremented after public or commercial releases of the software so that users can distinguish between product versions using a Major.Minor version number.
Revision
The revision number is a number starting at 1 and incremented each release.
Artefacts
Files
- VERSION.MAJOR
- VERSION.MINOR
- VERSION.REVISION
- VERSION
- RELEASE
Every project will have five files in the project root, being: VERSION.MAJOR, VERSION.MINOR, VERSION.REVISION, VERSION and RELEASE. The VERSION.MAJOR file has a single integer greater than or equal to '0' being the major version of the software under development. The VERSION.MINOR file has a single integer greater than or equal to '0' being the minor version of the software under development. The VERSION.REVISION file has a single integer greater than or equal to '1' being the revision of the current release. The VERSION file is updated based on the contents of the VERSION.MAJOR, VERSION.MINOR and VERSION.REVISION files with a full version number in the form Major.Minor.Revision. The RELEASE file contains the UTC date and time of the last release in the format YEAR-MONTH-DAY-TIME, where YEAR is a four digit year, MONTH a two digit month, DAY a two digit day and TIME is a six digit representation of the 24 hour time the release was made. The RELEASE file is out-of-date after a release is made so it is updated with the content "development" in between releases.
Branches
The code for the latest version lives in project/trunk. When a major or minor version is incremented project/trunk is branched into project/branches/version/MAJOR/MINOR for the previous version. So you start work on development version 0.1 and you release it as 0.1.1. You then decide to increment the minor version to 0.2. When this happens the current 0.1 version is branched to project/branches/0/1 then the project/trunk/VERSION.MINOR file is incremented to 2.
Tags
Tags are created in subversion for each release. For each release there are up to three tags created from the branch being released:
- tags/latest (only for releases from trunk)
- tags/version/MAJOR/MINOR
- tags/release/YEAR/MONTH/DAY/TIME.
Processes
Minor upgrade
A minor upgrade can only be done on trunk. For a minor upgrade first a branch of trunk to project/branches/MAJOR/MINOR for the current version is done and then the VERSION.MINOR file is incremented and the VERSION file reconstructed.
Major upgrade
A major upgrade can only be done on trunk. For a major upgrade first a branch of trunk to project/branches/MAJOR/MINOR for the current version is done and then the VERSION.MAJOR file is incremented, the VERSION.MINOR file is reset to '0' and the VERSION file reconstructed.
Release
For a release first the RELEASE file is updated with the YEAR-MONTH-DAY-TIME of the release. The VERSION.REVISION file is incremented by 1 and the VERSION file is reconstructed. These changes are committed to the repository. Then the released branch is forked to project/tags/version/MAJOR/MINOR and project/tags/release/YEAR/MONTH/DAY/TIME from either project/trunk or project/branches/MAJOR/MINOR depending on which branch is being released. If the release is from trunk then project/tags/latest is updated too. After the release has been tagged the RELEASE file content is replaced with "development" and committed back to the repository.
