I never really liked the standard version numbering theme “x.y.z-w”. The main reason I don’t like it is that you can not really distinguish the scenarios “working on version two” and “working on a patch for version one”. Both version numbers would start with “1.”. Some projects use the following version number scheme to distinguish these scenarios:
- 1.0.12 The 12th patch for version 1.0
- 1.99.12 The 12th development snapshot of version 2.0
As I said before, this seems a little bit strange to me and so I tried a new version numbering scheme on my recent private projects. Version numbers always consist of 3 parts: The major version number, a qualifier and a revision number for the qualifier. Suppose you have the following file name for a project deliverable:
foobar-server-v01ds05.zip
This file name has the following general format:
project-name-major-versionqualifierrevision.extension
The major version number and the revision number are just numbers that are incremented with every version. The interesting part is the qualifier which specifies the kind of release of this version. The kind of release is one of the following: “Development Snapshot”, “Beta”, “Release Candidate”, “Production”, “Maintenance”. For these kinds, the following qualifiers are used:
- ds Development Snapshot (I used to use "dr" for "Development Release" but I now think "ds" is better)
- be Beta
- rc Release Candidate
- pr Production
- mr Maintenance Release
The development history for foobar-server could then look like this:
- foobar-server-v01ds01.zip
- ...
- foobar-server-v01ds11.zip
- foobar-server-v01rc01.zip
- foobar-server-v02ds01.zip - started development in the "v02" branch
- foobar-server-v01pr01.zip
- foobar-server-v02ds02.zip
- foobar-server-v01mr01.zip - We found a bug in v01pr01
The production release would not really need a revision number (since there is only one production release for a given major version), but I think it is better to add the “01” so the version numbers are aligned.
