Version Numbers

Software releases are usually given a version number to differentiate them. Different projects use different schemes for their version numbers, but perhaps the most common is the x.y[.z] scheme. In this scheme, the x denotes the major version number, the y denotes the minor version number and the optional y defines the patch version number. For example:

The patch version number is increased each time a release is made that fixes bugs in previous releases but does not add significant new features.

The minor version number is increased each time a release contains significant new features.

The major version number is increased when a new release breaks backward compatibility in a significant way (although see discussion on postfixes below). Or, in the case of version 1.0, when the software reaches its first release that is considered fully stable.

Quality Postfixes

Some projects use postfixes in the version number to indicate the stability of the code. For example, "-alpha" indicates unstable code, while "-beta" indicates code with a stable API but that may still have bugs in it. Other projects use the minor version number to indicate stable/unstable code by using an even number for stable releases and an odd number for unstable releases.

In this context "unstable" does not mean "unusable". It means that the code may change in the next release. Alpha releases are only to be used if you are prepared to put the effort into maintaining your software when it comes to upgrading. This may require some manual steps in the upgrade.

Software will typically follow a release cycle something like:

Version Number using postfix scheme

Version number using odd/even stability

Status

Who should use it

0.1-alpha

0.1

Unstable

Those willing to get their hands dirty and experiment, especially when upgrading to the next version

0.1

0.2

Stable

Early adopters

0.2-alpha

0.3

Unstable

Those willing to get their hands dirty and experiment, especially when upgrading to the next version

0.2

0.4

Stable

Early adopters and those wishing to use the new features

0.3-alpha

0.5

Unstable

Early adopters and those wishing to use the new features and willing to work at upgrading on the next version.

...

...

...

...

1.0

1.0

Stable

Everyone

1.1-alpha

1.1

Unstable

Early adopters of new features and willing to work at upgrading on the next version.

1.1

1.2

Stable

Users wanting new features

...

...

...

...

2.0

2.0

Stable

Everyone willing to go through the pain of upgrading a potentially backward incompatible release in order to get the cool new version

...

...

...

...

Note this is only indicative, different projects use different schemes, this table is not intended to indicate the status or stability of any real software project. The above table does not concern itself with minor revisions (bug fixes and the like).

As can be seen, release numbers in open source tend to be far more conservative than release numbers in closed source. It is not uncommon for a 0.x open source release to be as feature rich as a 1.0 commercial release. This is a by-product of the ReleaseEarlyReleaseOften approach to software development.

Release Candidates

A Release Candidate (RC) is a version with the potential to become final if others find that it works. That final version is also referred to as the Gold (or General) Release.

Further Reading

http://en.wikipedia.org/wiki/Release_candidate

OSSWatchWiki: ReleaseVersionNumber (last edited 2013-04-15 13:56:19 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.