Software versioning is important as it makes it easy to identify changes between software at different points in its life cycle. For instance the code used for a particular paper should be identifiable as a particular version of the associated software.
There are a lot of reasons for updating the version of software. These range from producing release versions to "in house" versioning to help you keep track of the software's stable states. Some examples:
New features
Completed repairs
Updated dependencies
To match a publication
To test on other platforms
For a stable platform for further development
While versions can be done using any consistent style there are several more popular systems for describing versions. The standard we will describe here is developed for Python and can be found as a Python Enhancement Proposal, PEP 440.
Like most versions it has several parts to help describe a new version and the changes which have been made, for public releases:
Epoch segment: N!
Release segment: N(.N)*
Pre-release segment: {a|b|rc}N
Post-release segment: .postN
Development release segment: .devN
In terms of our standard initial version:
Epoch: None
Release segment: 0.0
Pre-release segment: 1
Giving us an initial version of 0.0.1
We can extend our "release" versions with local versioning. There are only basic restrictions on local versioning. They should be separated from the public version with "+" and must start and end with an ASCII character or number.
For example I might want to develop several new features before releasing a new public version, after the first feature is developed I might reversion my code as:
0.0.1+NF1
Which could be incremented as I added more features.
We can break down the types of version updates into a few categories:
Major - A large and substantive change that effects how the software is used, might include major new features or changes to interfaces.
Minor - A substantive change that effects the capabilities of the software, might include a new feature or an expansion of an existing one.
Patch - A small change that repairs or corrects the software, might include bug fixes, improved compatibility with other software or repair of a security concern.
Pre - versions - Allow us to make a version for testing before releasing the full version for any of the above updates.
Examples of updated version:
Type - Before version - After version
Major - 1.3.0 - 2.0.0
Minor - 2.14 - 2.2.0
Patch - 4.1.1 - 4.1.2
Premajor - 1.0.2 - 2.0.0a0
Preminor - 1.0.2 - 1.1.0a0
Prepatch - 1.0.2 - 1.0.3a0
If your working with version control software it is recommended that you develop on a seperate branch to your stable main branch. For updating versions this means that you should consider updating your version when merging with the main branch.