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/

Re:Semantic Versioning

[Junta]

Got an example at hand?

foo 1.2.3 and foo 1.3.4 might both release as independent stable branches. 1.2.3 might release after 1.3.4, and that would be ok. Ditto for foo 2.1.3 releasing before 1.9.20. So in terms of the upstream, it's perfectly capable of describing concurrent releases.

If you refer to giving room to linux distros to ascribe another tier of versioning, that's why packages append their own revision and flavor (e.g. -5.el6 and -10.el7 may refer to both different generations of the package targeted at RHEL/CentOS6 v. 7.

If you are instead referring to some sort of disagreement in how the project moves forward, that's a fork with a rename (e.g. Gnome v. MATE, Trinity v. KDE),

Not seeing how that argument stands against semantic versioning. Arguments can be made whether or not one can meaningfully honor the promise of the versioning for very large, complex projects, but at least for smaller projects it's a reasonable enough approach.

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.

Re:Key rules.

[halivar]

What happens when it goes beyond Z? Does it go onto [?

0. I'm on EBCDIC, you insensitive clod!

KISS

[Moof123]

Please keep this crap simple. It is maddening for secondary tools (ones I don't use daily) to get all cutesy with the Silky Lizard release, which is also known at the 2015 release, but has an about me of 3.2.0.1 hotfix 430. Searching under all three is necessary since everyone adopts a different preferred method to refer to the dang thing.

On the whole I greatly prefer versions that are year.month based so it is very easy to recognize how long in the tooth something is. XYZ 2015.01 tells me it is the January 2015 release.

Re:KISS

[Junta]

On the whole I greatly prefer versions that are year.month based so it is very easy to recognize how long in the tooth something is

Of course there are situations where that really does not matter and fretting about how old a piece of code is pointless worrying. For example, the code to decrypt a DVD hasn't change in an eternity, but there's no good reason to expect a change to be needed on that front. A library dedicated to that purpose might not change because there's no point, not because it's abandoned.

Re:I'm running Chrome 45 and Firefox 41

[bluefoxlucid]

People don't consider a lot when they do things. There's an old convention of 0.x being "incomplete", such that we have some rather mature products in pre-1.0 stable releases without all of the features and finalized interfaces which constitute a completed product. There's a newer convention of Major.Minor.Revision, based on the old Major.Minor.Revision, by which "revision" means "nothing new, fixed some defect", while "Minor" means "Something new, works exactly as before if you're not using the old thing", and "Major" means "things that you did in the last major may produce different results in this version; that includes the removal of features we previously deprecated."

Upon these conventions, we've built support conventions. The prior major release, at least, usually gets continued bugfixes, and occasionally feature back-ports. Bugfixes are for people who can't move forward just yet--they need to fix their processes and workflows to use the new version--and need that support, especially for security fixes; while feature back-ports let the client keep up with new developments, accessing some features in the new major which don't depend on new behavior of old features. We usually handle this by giving a shorter and more casual minor-update duration (you get new features when we care to backport them, by user demand, only for 12 months) than we do for bug fixes (the final 6.x release gets bugfixes for an additional 12 months).

Then you have the deviants.

Apple, upon releasing a new Quicktime major, will preemptively stop supporting the last major. When Quicktime 7.0 came out, it fixed major security vulnerabilities in Quicktime 6; Apple provided no updates to Quicktime 6, so those vulnerabilities remained unless you upgraded to a whole new major Quicktime version with new APIs, new features, changed behavior, and some features removed.

Then you have Ubuntu and Debian, who follow a very clear policy: Each release will receive no updates which change any functionality. If it worked on release day, it will work in exactly the same way at EOL. Bugfixes may enable previously-broken functionality; they try not to alter functionality such that previous work-arounds start behaving differently, unless the application is so crippled as to be unuseful. This is okay because the scope of a distribution release implies a major change; Ubuntu has a point release system for LTS to signify minor feature updates.

RedHat takes a different, more Apple-like approach: Their point-releases are just inline updates, like Ubuntu LTS; but they're *major* updates, removing old features and subsystems, integrating completely new systems, changing behaviors, and generally breaking all kinds of shit. There's no support for the previous point release, at all; if you call RHEL support, they tell you to update or else they have nothing for you. The difference between RHEL 6.10 and RHEL 7 is functionally similar to the difference between RHEL 6.9 and RHEL 6.10, or RHEL 7 and RHEL 7.1.

Bring that out to Chrome, Firefox, and friends, with an iterated version for every release. Release numbers now have no meaning except "new". They are effectively date stamps, without the benefit of Debian-style releases in which every release is implied a drastic upheaval rather than a possible incremental feature increase. Nothing in the versioning indicates if APIs have changed or been removed, so broad assessment of compatibility risks (e.g. with old protocols, old incorrect rendering behavior, or old extensions) are not as readily assessed.

It goes all the way out to the Linux kernel, which is just nonsense. WhenLinusFeelLikeIt.Otherwise.Bugfix is the Linux kernel's pattern; it's essentially Major.Bugfix with a period in the Major part.

Re:Versioning and Releases Are Old School

[fisted]

with continuous release.

Ain't no rockstar brogrammer got time for releng, right?

Our software version is whatever the Git hash is.

You're saying this as if that was something to be proud of, rather than a demonstration of laziness...

This is for a large computational science library that's in use by hundreds of researchers around the globe.

Thanks for the warning.

Do it with Panache?

[FatdogHaiku]

OK, but I'm still on Panache 0.92.4!
Do I need to update to 1.1.x?
Also, it would seem that certain young women on the internet have Panache x.x.x.