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?

[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.

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!

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.

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!"

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!"

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.

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