Torvalds schedules Linux kernel 5.0, then maybe delays 'meaningless' release Linus Torvalds has suggested that the next Linux kernel could earn the number “5.0”. Torvalds’ suggestion came in his announcement of the first release candidate for version 4.17, which he said “does not seem to be shaping up to be a particularly big release, and there seems to be nothing particularly special about it.” …
I agree. Every single update ever made is usuall for either adding functionality or adding more code to improve existing functionality. Removing functionality has practically never happened, especially at kernel level.
And it will likely not happen again before quite a while, because when we get to the point where we can retire x86 architecture, well I think Linus won't even be around to do the removing.
And neither will most of us.
This post has been deleted by its author
This post has been deleted by its author
<PedantMode><Apologies>
Strictly speaking, a lot of the "Linux" kernels out there (RedHat's, Android's, etc) are modified versions of the main stream source code. So whilst they're very Linux-ish, they're not quite pure Linux.
And if one considers a kernel's system call interface to be what makes it a "Linux", one would have to include Windows 10's WSL, and the Linux binary interfaces on Solaris, FreeBSD, and indeed QNX. So the code that the heroes and heroines in the Linux kernel project work on is just 1 of 5 implementations of "Linux".
So whilst the article is broadly right in saying that Linux is the most used kernel on the planet, it's a bit of a vague stat.
</PedantMode>
Seriously though, great stuff, thanks very much!
I'm pretty sure that one of Linus' pet hates is anything that breaks user land. I'm not aware of any significant change in the system call interface in quite a long time.
If there's no breaking changes in the kernel, they're left looking for other reasons to go up a major version number. So really that's a license for doing, well, anything he wants.
"I'm pretty sure that one of Linus' pet hates is anything that breaks user land. I'm not aware of any significant change in the system call interface in quite a long time."
The article says however that certain hardware support is deleted in this edition of the kernel - that sounds break-ish to me.
"Breaking" can also be see the other way round - i.e. something written targeting v.5 explicitly can't work on v.4 (because of using new calls not available previously), while you do expect something written for 4.17 will still work on 4.5 because I don't expect anything new added at the interface level.
Otherwise, I can't really see why Linux doesn't switch to a single incremental number for the kernel version. Sure, one day you'll be using kernel 12333, who cares, if the numbers don't convey any useful information?
That depends on the definition of Progam.
If Program is anything in-kernel it breaks as regular as a couple of versions for the more complex stuff. Example - the changes to timer APIs and moving from an explicit callback to "container-of" style of obtaining the caller. That was a fairly major breakage in third party/out of tree modules.
If Progam is anything out-of kernel. Linux userspace facing APIs have had little or no changes since ~ 3.0. The syscalls remain the same and with the same args.
Only if you explicitly use semver or similar.
Linux does not.
"You have been warned" i believe is in reference to other problems in the kernels lifetime caused by people trying to apply meaning to major and minor version numbers.
Linus is just reiterating that this is a bad idea in the case of Linux
Its probably a bad idea to assume numbers move forward, given the number of forks.
"Surely a primary version number update is when you are breaking compatibility with the previous version. Basically you are saying Program X will work with Version Y.*, but we cannot guarantee that it will work with Version Z.*"
I am not a linux expert but version 2.4 and 2.6 for example changed the kernel API which broke (every?) drivers. It was a surprise and shock and meant I had to port across various drivers. It probaby should not have been a shock but I use lots of different operating systems and what is the point of major and minor versions if you don't use it to indicate compatibility?
> “But v5.0 will happen some day. And it should be meaningless.
If Torvalds wants to be unpredictable he should call the next release -6, or 'smørr' or something else "meaningless". It would be a small and meaningless act of rebellion. Much like the 4.17 release is looking like.
Personally I prefer step-changes to release numbering to signify meaningful and major changes to the functionality of a product. Not linked to some irrelevant administrative exercise like lines of code or commits.
"or Linux X...."
So that would be LinuXX, to be followed by LinuXXX.
Paris, coz I hear she likes being XXX sometimes.
Edit:
"Everything seems to be version 10 nowadays, so why not join the bandwagon"
And I noticed that after upvoting you, you now have 10 upvotes. You bandwagon jumper you.
Version numbers are an artefact of the pre-internet era way of doing software development.
With today's continuous release and cloud platforms (github, etc) they should just dump out the version numbers completely and go for YYYYMMDD-style date stamps.
e.g. "release 20180416-S" has a lot more information included in the version than "release 4.15.whatever-rc3" - it indicates right there in the name WHEN it was the last release and whether it was a Stable or Release Candidate.
>>"Version numbers are an artefact of the pre-internet era way of doing software development."
Spoken by someone that has done a very narrow range of software development or none at all..
>>"With today's continuous release and cloud platforms (github, etc) they should just dump out the version numbers completely and go for YYYYMMDD-style date stamps."
Out of all the possible reasons for versioning software this has to be the absolute least useful information and format.
Software versioning is used by other software developers, not the end-user (except possibly to identify & report bugs/problem with a specific version).
Software versioning is important if one is maintaining other software packages that may have to be backwards/forwards compatible and may take a long time to release and get certified for use.
The concept that every piece of software is constantly undergoing change and release with every other piece of software is just plain idiotic, not to mention wasteful of developer's time.
Relating the mechanism (continuous releases) to why version numbers are important is meaningless.
You can call me old-fashioned, but I'm not the one rewriting the same code every other week because someone decided to change the story-board. I have better things to do with my time. Get the requirements right the first time..
>>"e.g. "release 20180416-S" has a lot more information included in the version than "release 4.15.whatever-rc3" - it indicates right there in the name WHEN it was the last release and whether it was a Stable or Release Candidate."
Who the fuck cares when a software package was released? Again useless information. Your statement indicates, that you really haven't a clue as to why / how version numbers came into existence.
Obviously, you have never written software for an embedded system where everthing is not always upgradeable in the field, nor should it be.
Not all software developed is the weeny-wanky web-based crap apps used on phones who's only real purpose is to mine your personal data for free.
For those who didn't quit reading (;tldr). Thank you.
The concept that every piece of software is constantly undergoing change and release with every other piece of software is just plain idiotic, not to mention wasteful of developer's time.
Anyone trying to do low-level Windows API-based stuff on the shifting sands of Windows 10 will concur with that, I'm sure.
"You can call me old-fashioned, but I'm not the one rewriting the same code every other week because someone decided to change the story-board. I have better things to do with my time. Get the requirements right the first time.."
Do you have a current full time career in software development or are you retired or more of a hobbyist perhaps? I have spent the last few decades asking clients (mostly 'business analysts') to provide better functional (and non-functional) requirements. Rarely do they provide the 'right' requirements first time i.e. something that can be used to design an 'acceptable' solution without significant change during the development and test schedule. This has been true for even the simplest of IT infrastructure or software development projects, half the time they push it back and say something along the lines of 'you're the IT contractor, it is your job to tell/sell us what IT we need!' so the new shiny is thrown at them regardless of it being fit for their (business) purpose. Anyway, version numbers can apply to requirements not just code, welcoming changes in requirements may be one of the agile development principles (responding to change over following a plan) but that doesn't make it a rule :)
>>"Do you have a current full time career in software development or are you retired or more of a hobbyist perhaps? "
25 year career. 12 as a consultant, 13 as an employee. Hopefully with another 10+ to go.
For me, the difference is as a consultant, someone wants to change something, they pay for my time either way. As an employee, I have some say in the matter as to inputs into requirements and also make it clear how any changes will affect delivery times.
Re: requirements - I version them frequently, eventually they do get tracked back to a version that's released.
I don't really do too much with direct IT type of activities anymore.
I wonder how many organizations that use an agile style of development use contract employees - it's expensive to do so. Agile seems to work for smaller projects and colocation is almost a given, I've never seen it scale well to larger projects and also not on projects where certifications are required. I once worked on a project that involved a combined 600 SW & HW engineers across the globe. To do so without formal requirements would not have worked.
IMO agile appeals to younger coders because it gets them coding almost immediately and away from having to work on (the boring) requirements docs and it appeals to management because they don't have to worry about them as much either. So the end result is code early and recode/refactor often. I kind of get tired of recoding and throwing away code on a monthly basis.
I can point to products that have been out in the field for 20 years that I contributed code to, I get a very large sense of personal satisfaction from that, not something that's going to disappear from the web in a couple of months - but that's just me, some people just want a paycheck..Not that there's anything wrong with that at all - we all need to eat..
go for YYYYMMDD-style date stamps
I used to work with a guy who liked that numbering scheme.
He was one of the biggest assholes I've ever had the dubious pleasure of working with, for many reasons unrelated to his release numbering preferences.
Ever since then, I've had an irrational dislike of date-based release naming.
You never used branches and had to merge changes across them, taking care of different releases at the same time, right? Just a single line of development, right? It may work for simple applications when there's at most one release in production, and bug fixes are made only to the latest one.
Also, Windows executables - if you need to keep them in sync with Linux versions - don't support timestamps in the numeric version field of their resources, which is less ambiguous when checking for a file version.
As a software tester who sometimes struggles with the concept of automated testing for multiple version trees that should (in theory!) regularly merge back into a single trunk, I was initially inclined to agree with you. My problem is that sometimes the master trunk code must be rolled back a few versions but with new timestamps (where files are unchanged but still touched), perhaps due to a nasty defect that somehow an automated regression pack didn't include as it was not updated in time itself or just mistakenly switched off. These are often due to a new feature in the (more regularly updated) alpha/beta test code combined with simple human error. I think a much better approach for tracking is a balance of using timestamps inside an archive plus another unique identifier for an overall archive of all code, such as a secure hash checksum of all source files when archived up into a single file. As long as your continuous testing system does a sense check of all the (individual and combined) hashes then it should be able to keep track of any particular version change/merge or other activity, including whether a rolled back change puts the hashes back as required, regardless of timestamps. I think this may be how some of the better version management solutions function internally but I've not yet been tasked with testing any of them :)
'Cos that's just plain silly willy-waving.
Version numbers are meaningful in a few ways:
Compatibility breaks. There are always lines where forward, backward and interoperability compatibility can't be maintained.
Feature checks. Features get added, replaced and removed.
Downgrade. It might not be practical to downgrade back to the previously-installed afterwards.
Upgrade stages. It might not be possible to support upgrading from all prior versions.
It is very useful to signal these barriers in the version number, or to at least make it easier to document - "Compatible with 3.x and 4.x" etc.
- Marketing tends to ruin all the above of course, commonly with either "big numbers are good" willy-waving, or by requiring particular numbers for particular features. "Can't call that v2, we promised feature Y would be in v2!"
I enjoy willy-waving as much as any man stuck in early adolescence, but Linux, like many complex pieces of software, needs at least one dot in its version numbers because typically there are multiple branches in active development, while consecutive integers are easier to remember than dates, and it's easier to guess whether there was a release between 2.17 and 2.19 than if they were called 2.20170203 and 2.20170809, so let's leave the willy-waving for the changing rooms.
That occurred to me back in the days when the Linux roadmap seemed to suggest that the version number would be stuck at 2.6.x forever. In that case, why not just drop the "2.6", just like GNU Emacs 13 or Java 5. But then, I didn't expect he'd come up with the genius idea of bumping the major version number for no good reason at all....
Your mother was a hamster and your father smelt of elderberries!!!
Sorry, I'll get me coat. The one with the Holy Grail in the pocket please
On a serious note, I feel "meaningless" means less work, and "meaningful" means more work for those updating to the latest kernel. I am all for meaningless!
...if you are working for PHB, there is tremendous fear and loathing at any disturbance in the force. If the kernel version has three significant digits and the least significant one changes, we can generally upgrade, choose not to, whatever and get our jobs done. When the most significant digit changes? Grab your bug out kit and head for the hills! The accreditation, certification, bustication, masturbation, and every other freakin' *ation department will rise from the dead and demand their pound of flesh.
I'm begging you, no 5.0 please!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
