Romance and Rebellion In Software Versioning

joabj writes: Most software releases more or less follow the routine convention of Major.Minor.Bugfix numbering (i.e. Linux 4.2.1). This gives administrators an idea of what updates are major ones and might bring compatibility issues. As Dominic Tarr points out in his essay "Sentimental Versioning," a few projects boldly take on more whimsical schemes for versioning, such as Donald Knuth's use of successive Pi digits to enumerate new updates to TeX, or Node.js's punk-rock careening between major and minor releases. If you break convention, Tarr seems to be arguing, at least do so with panache.

Comments

Semantic Versioning

[bondsbw]

http://semver.org/

Sofware versions should stop at 10 . . .

[PolygamousRanchKid]

Some can go up to eleven, but most should stop at 10.

Use Gödel numbering

[vikingpower]

Use one series of primes for major.
Use a second series of primes for minor.
Use a third series of primes for patches/micro/bug fixing.

The three sets of primes should be disjoint.

For each release, multiply major with minor with micro. That is your unique version number.

You may add some sugar by adding powers of these primes for various locales, database compatibility etc. etc.

Key rules.

[jellomizer]

1. Stay Consistent!!! Don't drop your versioning and swap to another one. Like Microsoft, Firefox, to a lesser extent Apple.
2. If you are using names make sure you know which one is greater. Ubuntu method of going up alphabetically is a good example.
3. Insure development milestones are consistent with the version bumps. So Version 2 to version 3, should be just as large as from version 3 to 4.

The key importance to versioning is so we know what is the newest/newer version and if you have a major version you will expect some compatiblity changes.