Slashdot Mirror

This is how Semantic Versioning ought to work:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

So, while Linux kernel version numbers may be meaningless, it would perhaps be better if they were actually meaningful.

Many version numbers in software are meaningful.

If anyone depends on your software, then using major/minor/patch version numbers to distinguish which changes are backwards incompatible, feature additions, and bug fixes is very helpful to those downstream. See https://semver.org/

updates usually have version numbers and version numbers have a tendency to increase.

Then why increase the major version number rather than the patch level? There's a difference.

Semantic versioning. It's not perfect, but it's a thousand times better than the insane major version bumping you're doing. When was the last time you crazy kids released an xx.1.0 version? What's the point of "43.0.1" if there's essentially zero chance you'll ever release "43.1.0" in the future?

It seems that many projects now opt for a regular progression of numbers with or without any major new features. Even Ubuntu releases, formerly the occasion for the introduction of some initially broken new feature, have become boring affairs. Even the well-numbered Linux kernel appears to break the major.minor paradigm. Besides the addition of more and more drivers, was there anything particularly disruptive in the move from Linux 3.19 to Linux 4.0? Beyond the third digit of the bug fix releases, Linux version numbering fall more into the sentimental rather than semantic versioning camp.

http://semver.org/

So the huge increase in complexity is annoying, but I would argue that breaking things from version 1 to version 2 is both acceptable and expected, especially if the project follows semantic versioning (which I wish every project did).

Follow the Ubuntu versioning scheme, it's simple... kernel was release in Febuary 2015, then you would call it 15.2

This makes sense for Ubuntu because it has regularly scheduled releases (two a year, YY.4 and YY.10). This does not make sense for the Linux kernel because it does not have regular releases. Also, Ubuntu is a distribution, meaning that it pretty much never releases "major" features, and there is no distro-level API to break compatibility with, so it makes no sense for Ubuntu to use something like Semantic Versioning.

So dates don't make much sense, at least as major versions; something like dates as minor versions or patch levels would work though, so long as the major versions still make sense, e.g. 4.0.20150301.

This means we (Linus) would still have to deal with defining major (and possibly minor) versions.

Thats the Semantic versioning convention:
http://semver.org/

I'm not really sure because I don't know if Linux adheres to Semantic Versioning or not (previous bumps in the major version number might suggest not). Semantic versioning doesn't work for every project but I am pretty sure that (if Linux used semantic versioning) that the next release would not introduce any incompatible changes to the API/ABI.

I think more people are starting to use semantic versioning: http://semver.org/

The gist of it is:
Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

This way the numbers actually mean something in a somewhat consistent way across programs.
npm packages use this for example.

.NET Core will now use semantic versioning. I'm not sure if .NET Framework will do the same... I don't know of anything planned for 4.6 that violates the rules of semantic versioning.

The overall synchronized release of .NET will now be labeled by year, e.g. ".NET 2015".

No.

Which is why we need for these applications to switch to semantic versioning ASAP.

Having googled semver, I think the version number may have something to do with this.

http://semver.org/

Last time I checked, KDE makes releases nearly every two months. Too-rapid releases with major API changes (such as the ACPI changes in 3.2) can cause rather annoying problems with third-party drivers.

@World, if you're going to use a three-part version number, please follow semver. Don't make API-breaking changes in a minor version.

I am always fascinated by Linux version numbers. I can't quite figure out what they mean, and I suspect I'm not the only one. Reading that "2.6.40 is more distinct from 2.6.0 than 2.6.0 was from 2.0.0" doesn't make any sense to me. For my projects, I have always intuitively followed the Semantic Versionning principles: x.y.z, where X is a major version, Y is a minor version and Z is a patch release. You increment X when you change the API. You change Y when you add a feature. You change Z when you make a small bugfix. Simple and clear. Linux, on the other hand, seems to follow more the whims of Linus than any logical process, which seems to be a common pattern in this project, and which is not always for the worst though...