Slashdot Mirror
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.
...so we can all worry about stuff like this.
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?
Why not just skip directly to Linux 10?
Richard Stallman can help.
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.
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!"
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
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
WWII tank name conventions! Linux SuperKernel M4A0
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)
Just call it OS L and be done with it.
"No it's not OS el you incompetent hag, it's OS fifty!"
Super Hyper Insane Turbo Linux Alpha 4 Extreme Edition
It makes me sad. Not about version numbering. Why does Linus force the users to use Google+. It somehow feels very wrong to me.
Linux isn't used by morons.
You must REALLY be new here.
Why not adopt the new standard, jump your major revision number to 10, and then leave it there forever; just like Apple and Microsoft?
Ask me how the Heisenberg Principle may or may not have saved my life.
Since Linus is essentially saying that the version number is meaningless now, just use the release date to keep track of things.
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.
Asking for people to vote on things?! Linus' email has obviously been haxxed.
"But vee had to change ze naming scheme; ze focus gwrooops liked 'Slightly Annoyed Kitten' better."
The main thing I'd like to see for 4.0 is a massive simplification of the kernel, removing features that are no longer used anywhere. There's a lot of duplicated functionality in the kernel - two different ways to report hotplug events, three different ways to report ACPI events, several dozen filesystems, some of which don't actually work or even have userland tools that will compile on modern kernels.
So I'd like to see a winnowing of kernel features, down to a saner, all-known-to-work set.
Also, can we please at some point make /proc a bit more sane? Why do I write kernel configuration parameters to files in proc? Why not to sysfs or configfs? /proc, IMHO, should just hold process information. It's confusing.
...but it's being eaten...by some...Linux or something...
For me the whole numbering of versions depends on how significant the improvements are? For example does Google's Chrome really need a whole number whenever it updates Chrome? When in fact its really just a incremental update? Or for that matter Firefox who basically does the same thing. I like the fact that companies like Apple don't take that whole number so casually, and does more with decimal updates rather then just making people think you took such a big step. Its like Microsoft skipping Windows 9 and going directly to Windows 10. We know they want to make everyone think they are taking a giant step away from Windows 8. If Linux is to improve its desktop user experience. I think defining the Linux kernel improvements between major and minor is important. We know that Ubuntu for example has a long term support vs a more frequent upgrade version. But many do not understand this. Ask many Linux users and they probably cannot tell you what kernel they have. But I suppose that goes for many users who don't really know much about their OS.
Follow the Ubuntu versioning scheme, it's simple... kernel was release in Febuary 2015, then you would call it 15.2
Will he just start over again, with a new kernel?
Save the major version bumps for large refactorings.
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.
the growth in cynicism and rebellion has not been without cause
When your driver architecture would require a refactorisation of nearly all the driver code, breaking many applications, then it's a major release. cf Win9x/WinNT.
When your kernel semantics would require a compatibility library or refactoring rewrite of your user code, breaking some applications, then it's a minor release. cf WinNT/WinXP.
It managed that from 1.0.2 to 2.6.39, why is it arbitrary now? Nothing new to change? Then drop the major number in "everyday speak", just like NT6.1,6.2,6.2.
Microsoft managed that, ferchrissakes.
Get with the trend guys.
Or just LinuX.
We have Chrome and Mozilla who for the most part dumped minor versions and we get a Major version every other week.
And then we have emacs where they dropped the major version number (see cute wikipedia story)..
In my mind a Major Number should be when there is a large change to the system.
On topic: Lots of things have changed in the linux 3.x series. For example the kernel now supports docker out of the box (if I recall correctly). This was added and improved over multiple releases, but there is a big difference between 3.0 and now. IMO, it's totally valid to make a major release...
:)
Anyways, at the end of the day, this doesn't matter. But it is so lovely simple that everybody can have an opinion about it. So taking a poll on the issue is certainly both sane and cool as it highlights just how unimportant it really is
Screw that - be a man and use Hexadecimal version numbers... wusses.
(warning: might cause *some* confusion initially, so don't take it seriously, eh?)
Quo usque tandem abutere, Nimbus, patientia nostra?
Is Pluto a major or minor planet?
IMHO a kernel must have a significant change to bump major version.
Everyone gives Microsoft example but "windows 8", "windows 10" are consumer brands. They really keep a very logical honest versioning scheme. For example, Vista is Win 6, "Windows 7 " which is said to be just fixed Vista is indeed 6.1
4.20, of course.
me too.
Cthulhu Saves.
Linus missed the knuth converge to pi opportunity.
Failing that, a 6 digit hex string is how nature intended it. One can then plot users graphically by version number.
If you ever run past 256 major versions, there's always the alpha channel. :)
People keep shouting here that google plus is dead, and that I'm the only person left on the entire planet who isn't on facebook. Why are we linking to google plus on the front page then? Is Torvalds on the google payroll now or something?
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Not that far from the truth.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Must pass Mac OS and Windows, jump to version 11.0!
Sleep your way to a whiter smile...date a dentist!
There's no point to the major version anymore, the only reason it's ever updated on the kernel is to make things more readable.
Agreed.
Having the year as the leading number doesn't imply major feature changes when you increment it, plus it solves the problem of huge minor version numbers.
It actually creates a problem where there is none. Same with the 2015.2 format, which I thought was the better plan before I read this thread.
Say we've got linux 3.20 now. It's easy for developers to think about what's on deck for 3.21 or 3.22 or 3.23 in terms of 'the next release', 'the one after that', and 'the one we're not really thinking about yet'.
When will those be released? I dunno - every other month, maybe? 2015.3 and 2015.5. Oh, but we slipped a week - now we're at 2015.6 and everybody has already been talking about 2015.5. It's just setting up a point of confusion in an environment without drop-dead release dates. The same applies for the work done in the December-January timeframe, just with the other digit.
What strikes me about that is that 21, 22, and 23 are meaningful for the developers but '3' isn't. So get rid of the 3. Do 22.1 if there's a revision, everybody can use (if $linux_ver > 22) without writing <=> overloaders, and then there's no arbitrary false semantic included any longer.
If releases continue on the every-other-month pace, we've got 322 years before '23' will be larger than '2015', so worrying about large numbers is still premature.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The kernel version numbers should just be the unixtime of their release. Or the number of days since the the first release.
Obviously, the next verision of Linux needs to be "Linux 11 for Computers" - we need to look more advanced than OS X and Windows 10.
Other variants can be "Linux 2015 Mobile Edition" for phones and tablets, and "Linux Server 2011 (Based on Linux 3.0 technology)" for servers.
I would change major when features change, and minor for bug fixes only.
That way you can quickly tell if your kernel has the exact same features than another one, and if you have got the same bug fixes.
Then yes, it would be a good moment to start with 4.0
Artix
Your Linux, your init.
Mr. T is usually not that interested in public opinion. So what happens when people vote to go for v4.0? Does he employ avalanches of abusive language because he thinks this is stupid?
... so I can stay away from it and know when to change to BSD
Atari rules... ermm... ruled.