Torvalds Polls Desire for Linux's Next Major Version Bump

jones_supa writes: Linus Torvalds made this post about Linux version numbering: "So, I made noises some time ago about how I don't want another 2.6.39 where the numbers are big enough that you can't really distinguish them. We're slowly getting up there again, with 3.20 being imminent, and I'm once more close to running out of fingers and toes. I was making noises about just moving to 4.0 some time ago. But let's see what people think. So — continue with v3.20, because bigger numbers are sexy, or just move to v4.0 and reset the numbers to something smaller?" To voice your opinion, the Google+ post allows you to discuss the matter and cast a vote in a poll.

Comments

Is semver too simplistic for kernels?

[tomxor]

Makes it sound like what determines a version bump is somewhat arbitrary, are kernels just too complex for them to fit into a simple versioning convention?

Re:Is semver too simplistic for kernels?

[jellomizer]

Version Numbers in general are outdated for application. The line between a Major and Minor version is huge.
We have been on Mac OS X (10) for 14 years. with have been getting point updates over the time.
Microsoft during that time has had 4 Major updates (That is with the insane longevity of XP).
We have Chrome and Mozilla who for the most part dumped minor versions and we get a Major version every other week.

In my mind a Major Number should be when there is a large change to the system. Going back and rewriting a lot of code, adding/removing features. While the minor version is just a patch, giving better performance, but the core architecture is nearly identical. Still in my mind, there is a lot of subjective debate.

Re:Is semver too simplistic for kernels?

[paulpach]

I adopted a convention for my software: x.y.z

"x" changes if there are some major features or change how the software works.
"y" changes if there are some new features.
"z" changes if there are only bug fixes.

Keeps it simple, easy to remember, and users reacted very well to it since they can immediately tell how big of a release it is.

Re:Is semver too simplistic for kernels?

[ArcadeMan]

If the kernel doesn't fit the usual versions model, why not just go with the freakin' date?

Linux Kernel 2015-02

Re:Is semver too simplistic for kernels?

[amck]

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

Re:Is semver too simplistic for kernels?

[mlts]

You hit the nail on the head. The problem, especially with mature platforms, is that big changes tend to not happen. We are not seeing any new bus architectures, nor are we seeing anything that fundamentally changes the kernel's architecture, so there are two schools of thought:

The first is to only bump up a major version number only if something radical happened, which the Linux kernel used to do (I remember back in the 1.x days, seeing 1.1.100.) Then there is bumping the major number routinely.

I'm of the former school of thought. Historically, a major number bump meant groundbreaking territory and for shops running it to be prepared for major bumps and hurdles. This is a good thing, since there needs to be large updates every so often, and bumping a major number warns of that.

Bumping a major number because the revision number is getting into the triple digits is, IMHO, more something a marketing person would do versus having an actual need for it. For example, the Windows version I'm using should be called Windows 6.3.9600. (Of course, even MS bumped the numbers up in Windows 10 of even the kernel.)

If Linux has to move to 4.0, there should be some reason to explain the jump to non technical people, be it a major feature added or something that adds a line of demarcation.

Without getting in a pro/con flamewar, I'd propose maybe adding kernel level hooks for SystemD without affecting functionality of Android and distros not using it. This way, the #1 program in userland has better interaction with the kernel, either for process management, raising/dropping privs for security, or other uses.

Re:Is semver too simplistic for kernels?

[flink]

Version Numbers in general are outdated for application. The line between a Major and Minor version is huge.
We have been on Mac OS X (10) for 14 years. with have been getting point updates over the time.
Microsoft during that time has had 4 Major updates (That is with the insane longevity of XP).

It depends on what you are talking about. The internal version number for Windows 7 is 6.1.x (Windows 8.1 is v6.3). So if we are going by marketing-driven release numbers, then there have been 6 or so major Windows NT release since 1996 (Windows NT 4.0, Windows 2000, Windows XP, Vista, 7, 8). However, if you go by the engineering version number there have been just 2: Window 2000 was NT v5.0 and Windows Vista was NT v6.0.

Re:Is semver too simplistic for kernels?

[Lodragandraoidh]

I would argue for adding an extra decimal point: W.X.Y.Z

'W' - Major Release - reserved for significant rewrite/technology/architectural changes

'X' - New Feature Release - significant changes to existing architecture/technology

'Y' - Minor Release - minor changes to existing architecture/technology - could be for major bug patches, or other miscellaneous performance enhancements that we want to differentiate from previous releases.

'Z' - Patches - things that do not rise to the level of a full release - could be for minor bug fixes, or to track iterative evolution and re-factoring of a small component of the overall system. Having the extra number here would allow you to keep each individual decimal number smaller by selectively rolling the number above it without necessarily impacting your major release numbers - basically it splits up the last number - which seems to get a lot of use - into two numbers to spread the load.

Re:Is semver too simplistic for kernels?

[HiThere]

I'd prefer:
2015-12-27rc, 2015-12-29rc, 2016-01-02rc, 2016-01-06!

Re:Is semver too simplistic for kernels?

[fph il quozientatore]

No, it's not. Semver mandates that the major version is bumped exactly when there are "incompatible API changes". This is a simplified (and les well-defined) version.

Why mess with v4.0?

[Anonymous Coward]

Why not just skip directly to Linux 10?

Re:Why mess with v4.0?

[arfonrg]

You can't just skip over Linux ME, Linux 2000, Linux Vista, Linux XP and Linux 8!

Re:Why mess with v4.0?

[Anonymous Coward]

Linux NT is the best. We can call it LiNT. Then wait for Mint to make a distribution based on LiNT.

"Do you run LiNT Mint?"

Re:Why mess with v4.0?

[Marginal Coward]

Please, oh please - can we at least skip over Linux Vista?

Actually, many years ago I tried to run Red Hat 6 (IIRC). I was new to Linux so I knew there would be a learning curve. But after a great deal of misery, I finally discovered that there was something fundamentally broken about the then-current version of GCC, and there was no possible way for a newbie like me to compensate. So, maybe that was the "Vista" moment of "the GNU/Linux system".

Since then, I've tried several Linux distributions and generally had a much better experience. Usually, I end up playing some of the games for awhile that come with it such as Tetris, then I try to get some basic Firefox plugins installed and maybe try to get audio to come out. After failing at those things, I go back to Windows. Then, a few years later, hoping that "easy" things have somehow magically gotten easy, I rinse and repeat.

Which reminds me - I haven't done all that for a couple of years. Heck, maybe 2015 finally will be my personal year of the Linux desktop. ;-)

Running out of toes?

[Anonymous Coward]

Richard Stallman can help.

Not quite sure

[Psychotria]

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.

Re:Not quite sure

[Anonymous Coward]

No, the Linux kernel does not have adhere to Semantic Versioning. For one thing, it is backwards-compatible until the last user of an userspace ABI either dies or sleeps on the job long enough (a few months) to not notice it is going away in the latest kernel if someone doesn't speak up. There are exceptions to this, mostly related to how painful it is to keep a feature still working, but they are very rare.

Note: internally the Linux APIs/ABIs change all the time, and breaking anything and everything that is not in-tree is fair game. The stability rules are for the kernel-userspace ABI *only*.

But it would be nice if we sync'd the major release bumps with something very user-visible.

Re:Not quite sure

[Rich0]

After 24 year, I think that if it were to become the MS monstrosity, it would have done so by now. Consider how many times the DOS/Windows kernel has been rebooted in that time.

I'm not sure MS is really the right comparison here. They're actually fairly famous for never breaking userspace. I wouldn't be surprised if Calc.exe from Windows 386 ran fine on Windows 8. Device drivers are a different matter.

Re:Not quite sure

[swillden]

It did adhere to Semantic Versioning before v3.0.

No, it didn't. The numbers did have some meaning before v3.0, but not the semver meanings. Prior to v3, the first digit, the kernel version, was incremented only when there were major changes, as there were from 0 to 1 and 1 to 2. The second digit had special meaning; even values were for "stable" releases and odd values were for "development" releases. This ended when Linus realized that it wasn't getting him the sort of testing he wanted of the development releases, and was also encouraging too-large changes in the dev releases. So, as of 2.6.0, that ended and all new releases just incremented the third digit.

They dropped it because Linus felt the "39" in 2.6.39 was too big.

Sort of. Linus realized that the path he was on would never increment any number other than the third, so it wasn't just that 39 was too big, but that eventually it was going to be 2.6.539, and that it was silly to keep carrying the immutable "2.6" prefix. Hence 3.0.

Personally, I think he should just take the next step and go to a single integer... 4, 5, 6, etc. Either that or use dates. Say, (year-2010,month), so a release today would be 5.2. The release candidate process Linus uses and the pace of development pretty much ensure that there won't be a need for two releases in one month, but if there is a second release in one month a subminor could be added (e.g. 5.2.1).

Why not use commit date as version

[What'sInAName]

Personally, I think it would be better to use the date as the version "number," though I'm sure that people who have thought about this issue more than I have can come up with reasons that's not a good idea.

One other idea, why not just use the git commit hash? That would really roll off the tongue and be easy to remember. I can see it now:

"Just released, Linux Kernel 634713bc047a87bf8eac9674765ae793478c50d2!"

Possible answer/solution.

[B5_geek]

I don't have a problem with the way it's currently done, but i have a possible solution that _might_ keep everybody happy.

based-10 numbered like an array.

You version numbers (minus the first significant digit) all go from 0-9, and once a minor-revision pushes a .9 up, it doesn't goto .10 it then reset back to a 1.0

i.e. so v4.9.0.10 = v4.9.1

Re:Want sexy versions?

[halivar]

WWII tank name conventions! Linux SuperKernel M4A0

Major Version == Major Changes

[HighOrbit]

I thought the point of a major version (not necessarily in the Linux kernel, but software generally), was to signal a major change that either:

• includes ground-breaking new features
• includes serious archtectural reworking
• breaks backwards compatibility

If the changes are merely incremental bug-fixes and minor feature additions, stay with minor versioning. Otherwise, you are not versioning; you are branding (viz: Windows 8... which IIRC is version 6.2)

Re:Major Version == Major Changes

[I'm New Around Here]

I thought the point of a major version (not necessarily in the Linux kernel, but software generally), was to signal a major change

Look at the choices in the poll itself:

1. I like big versions, and I cannot lie

You other coders can't deny.
When a kernel boots up with an itty bitty place
And a round digit in userspace
You get sprung

OS L

[io333]

Just call it OS L and be done with it.

"No it's not OS el you incompetent hag, it's OS fifty!"

Why Linus Forces users to use Google+

[Anonymous Coward]

It makes me sad. Not about version numbering. Why does Linus force the users to use Google+. It somehow feels very wrong to me.

Re:Why Linus Forces users to use Google+

[Anonymous Coward]

It's not like any blog hosting/software would be different. One still have to register to leave a comment - as it always was.

I guess I didn't get that memo.

Join the crowd

[swimboy]

Why not adopt the new standard, jump your major revision number to 10, and then leave it there forever; just like Apple and Microsoft?

Incremental development

[jones_supa]

It is artificial to bump the major version every time when the minor version merely begins to "feel too large".

The development of Linux is mostly incremental. A date code or just a single rolling number might suit the project better.

imposter!

[Anonymous Coward]

Asking for people to vote on things?! Linus' email has obviously been haxxed.

Follow the Ubuntu versioning scheme.

[nbritton]

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

Re:Well, that's one way...

[Rob Riggs]

You're an idiot. G+ is one of the tools people who actually make stuff use to communicate with their peers. It is very relevant to its users. Besides being relatively easy to use, it has one very important characteristic: a decent S/N ratio.