The myths about software version numbers.

Didier Spaier · 03-21-2016, 09:35 AM

In my opinion, this article from Jesse Smith is interesting for end users as well as software packagers: http://distrowatch.com/weekly.php?issue=20160321#myths

This reminds me the words of Patrick Volkerding in the email received by "root" after each Slackware installation:

Quote:

Some also think that any package with a larger build number is "better", when there have been many instances that a new upstream release wasn't working properly and we had to roll back to an earlier one, and an automated upgrade tool didn't want to "downgrade" the package. This is something upgradepkg will gladly do, as it doesn't (as it should not) take the package's version number to mean much of anything.

mostlyharmless · 03-21-2016, 11:10 AM

Indeed, the article makes many good points. It should be pointed out that many projects now also label versions as the latest "stable" release vs. a "beta" or "development" version. Unfortunately too, though, many proprietary/closed versions fail completely to document any sort of change log, making it impossible to rationally decide whether or not "upgrading" is actually a good idea or not. That's another fine reason for open source.

ntubski · 03-21-2016, 11:20 AM

Quote:

Originally Posted by the article

As an example, I have worked on a few open source projects which used incremental version numbers. For instance, 4.8 was followed by 4.9, then 5.0, 5.1 and 5.2. It was a surprise to me how often our mailing list received comments from our users along the lines of, "There are a lot of great changes in this update. It feels like more of a 5.0 than a 4.6." Or perhaps, "This 6.0 release sounds good, but I'm going to wait for 6.1 or 6.2." Both sets of comments ignored how the project's versioning system worked. It didn't matter if we piled on lots of new features or spent the entire release cycle working on bug fixes, in the end the version number went up an additional 0.1.

This kind of numbering is just needlessly confusing. The decimal point makes it look like there is a distinction between point release and major ones; there would be much less confusion if they just used 48, 49, 50, 51, 52...

ttk · 03-21-2016, 01:54 PM

Quote:

Originally Posted by ntubski

This kind of numbering is just needlessly confusing. The decimal point makes it look like there is a distinction between point release and major ones; there would be much less confusion if they just used 48, 49, 50, 51, 52...

You're just as guilty, here, of making assumptions about the methodology underlying a project's versioning as the examples you quoted from the article.

For some projects, numbers mean little. For others, they discern between feature releases and bugfix releases. For others, they discern between degree of feature differences. For many, they mean nothing beyond providing a chronological ordering. When git release hashes are used, they don't even mean that.

Semantic Versioning was created to try to formalize what versioning used to mean for most projects, long long ago. This formalization hasn't helped bring good practices back, unfortunately. It requires too much discipline, or something. http://semver.org/

Even with Semantic Versioning, though, what Volkerding says is spot-on correct. Knowing what version of a package is "best" requires (1) matching its features against users' requirements, and (2) thorough testing, to determine that the release is acceptably bug-free.

With Semantic Versioning, criterion #1 correlates loosely with major and minor version numbers, and criterion #2 correlates loosely with patch version numbers (but only within the context of a minor version; version 1.3.100 should be less buggy than version 1.3.1, but the bugginess of 1.3.100 and 1.4.100 cannot be usefully compared based on version numbers alone), but not enough to justify not testing.

If this all seems too complex, then you're best off assuming version numbers are completely meaningless, and leaving it up to folks like PV to do the hard work of figuring it out.

Richard Cranium · 03-21-2016, 08:04 PM

libtool supported another way to do things: http://www.delorie.com/gnu/docs/libtool/libtool_35.html

a4z · 03-22-2016, 02:59 AM

in libraries there is a sense in major.minor.patchlevel
patchlevel numbers mean binary compatibility to the same major.minor number
minor numbers add minor features, should remove none, but may deprecate features, (read feature as API call)
major number may remove/change and add features, or totally change the design of a library that you do nor recognise it any more.

for apps, like firefox, use what ever seems appropriate, but the name might indicate compatibility to some plugin interface, ..

what people have for meanings about numbers, everyone has an opinion and that's ok,
but the 'I do not use Zero in name version' folks are mostly not those with the greatest expertise.
even if some projects might release version zeros as 'hey please use the new thing and report problems', what is also OK, but not a general pattern.