Linux 5.0(lore.kernel.org)
lore.kernel.org
Linux 5.0
https://lore.kernel.org/lkml/CAHk-=wjuG6HiGbD7DCGfvDvhr_1WZUR-eYF2qWGbYyn9k6unvg@mail.gmail.com/T/#u
87 comments
"But I'd
like to point out (yet again) that we don't do feature-based releases,
and that "5.0" doesn't mean anything more than that the 4.x numbers
started getting big enough that I ran out of fingers and toes.
Similar to KDE 4.0 being beta and everyone lost their minds.
No, the big problem there was that KDE 4.0 was really alpha-quality, but all the distros just adopted it as-is and made it the only choice. So if you moved to a newer distro version to stay up-to-date with everything else a distro encompasses, you got stuck with KDE 4.0 whether you wanted it or not; the distros refused to continue to support KDE 3.x while the 4.x series matured.
That whole debacle can mostly be blamed on the distros, though the KDE team can get a little blame for their numbering scheme (moving from "3.95" or whatever to "4.0" and not explicitly calling it "alpha" or "beta"). The distros are the ones who are supposed to be exercising some quality control and making intelligent decisions about what to include or not, rather than just blindly throwing things in from other projects.
That whole debacle can mostly be blamed on the distros, though the KDE team can get a little blame for their numbering scheme (moving from "3.95" or whatever to "4.0" and not explicitly calling it "alpha" or "beta"). The distros are the ones who are supposed to be exercising some quality control and making intelligent decisions about what to include or not, rather than just blindly throwing things in from other projects.
My recollection of the events was that the KDE team was very much promoting 4.0 as a general release. The beta story came about later. Certainly the release announcement looks like a public release: https://kde.org/announcements/4.0/
Not really. Take a look at this blog post written right before the 4.0 release by kdesktop's maintainer who founded Plasma:
http://aseigo.blogspot.com/2008/01/talking-bluntly.html
To quote:
KDE 4.0.0 is our "will eat your children" release of KDE4, not the next release of KDE 3.5. The fact that many already use it daily for their desktop (including myself) shows that it really won't eat your children, but it is part of that early stage in the release system of KDE4. It's the "0.0" release. The amount of new software in KDE4 is remarkable and we're going the open route with that.
http://aseigo.blogspot.com/2008/01/talking-bluntly.html
To quote:
KDE 4.0.0 is our "will eat your children" release of KDE4, not the next release of KDE 3.5. The fact that many already use it daily for their desktop (including myself) shows that it really won't eat your children, but it is part of that early stage in the release system of KDE4. It's the "0.0" release. The amount of new software in KDE4 is remarkable and we're going the open route with that.
What's more, as I said before, it's the distro's job to do quality control, especially for something as critically central and important as the DE. Just look at Linux Mint and how their distro is all about their DEs; they don't just grab whatever some group says is "released" and slap it into the distro, they ensure all the parts are working together as intended and that the distro release is a coherent whole.
The distros at the time of KDE4.0 didn't do this. They just threw some stuff together without doing even the most cursory checking to make sure the thing actually worked decently as a desktop/workstation OS for users and put it out there, and then wondered why users were so mad about the unstable behavior.
The distros at the time of KDE4.0 didn't do this. They just threw some stuff together without doing even the most cursory checking to make sure the thing actually worked decently as a desktop/workstation OS for users and put it out there, and then wondered why users were so mad about the unstable behavior.
That is right. I think the excitement and hype around 4.0 was so much that everyone just wanted to released it. Which hurt KDE so badly.
These days KDE is amazingly stable, fast and feature-full. But the reputation and brand has not recovered from the 4.0 release yet.
These days KDE is amazingly stable, fast and feature-full. But the reputation and brand has not recovered from the 4.0 release yet.
> My recollection of the events was that the KDE team was very much promoting 4.0 as a general release.
That was what the community stated but I never found one single thing from KDE to state anything but a warning on not adopting for production.
I am still 100% mad how the community reacted to 4.0 and it wasn't fact based. Gnome would consume more resources but KDE = Bloat? Many would post showing how Gnome 2 was more resource hungry and we just got yelled at for being stupid.
KDE = most tied in OSS DE ouyt there and the rest were just window managers at the time.
That was what the community stated but I never found one single thing from KDE to state anything but a warning on not adopting for production.
I am still 100% mad how the community reacted to 4.0 and it wasn't fact based. Gnome would consume more resources but KDE = Bloat? Many would post showing how Gnome 2 was more resource hungry and we just got yelled at for being stupid.
KDE = most tied in OSS DE ouyt there and the rest were just window managers at the time.
I remember the transition from 2.4 to 2.6 being rather painful, whereas upgrading from 4.x to 5.0 would, no doubt, be a breeze.
Versioning is hard. Some people might claim that product A is better then product B because it has a higher version. Or they are getting annoyed by "lack of progress" of a semver not having major releases (breaking changes) often enough. People read too much into the version nr. Making a new version might be a way to get some news buzz.
On the other hand it's very useful for software libraries to detect breaking change. Lately I've found that node 8.14 added header size restriction that produce bugs, where it would've been easier if they just push to v10 instead.
However talking about kernel maybe it isn't that much needed unless significant feature and breaking changes introduced.
However talking about kernel maybe it isn't that much needed unless significant feature and breaking changes introduced.
That change was to fix a vulnerability, hence why it was made to the LTS version. A flag was later added to make it customizable (after they realized it broke stuff).
The problem is what is a breaking/major change for kernel? Is it referring to user-space API? The kernel ABI? Or the driver functionality/ABI?
That isn't versioning per se, that's just branding and marketing and bike shedding.
Not that I disagree with your point though.
Not that I disagree with your point though.
I remember it was briefly discussed but I cant search it on Google.
If it isn't a feature release schedule, why they don't have have the Year as Version number? So Linux 2019.1 or Linux 19.1 , The First Release of 2019.
If it isn't a feature release schedule, why they don't have have the Year as Version number? So Linux 2019.1 or Linux 19.1 , The First Release of 2019.
I'm not sure that it would be less confusing to do that. Old kernels are still maintained too, so you'd have new releases like 2018.42 still happening in late 2019. And then people would wonder why some server is running a "year old kernel" when exploits came out less than six months ago.
What's wrong with simple monotonically increasing digits?
What's wrong with simple monotonically increasing digits?
Exactly. For a real world example, Ubuntu's current LTS release 18.04 is running Linux Kernel 4.15 (released Jan-2018). Using a year version format it would be Linux 2015.15.
A lot of less technical people and fake security "experts" are going to freak out about a "2015" kernel. In general people seem less interested in how something is, than how something appears. That's why most companies still insist on password complexity rules and disable pasting to password fields, because it FEELS safer.
A lot of less technical people and fake security "experts" are going to freak out about a "2015" kernel. In general people seem less interested in how something is, than how something appears. That's why most companies still insist on password complexity rules and disable pasting to password fields, because it FEELS safer.
What about using a format like:
[Year of Initial Release].[Year of incremental release].[week of incremental release].[Incremental Number]
So:
2017.2018.39.332
[Year of Initial Release].[Year of incremental release].[week of incremental release].[Incremental Number]
So:
2017.2018.39.332
Dot numbers are supposed to signify something. Were.
Of course, modern software outside shrink-wrap context is evermore incremental and pushed to the customer in small deltas. Even Windows now tells me it's a "service and regular updates are normal procedure".
But look at Chrome is on like version 70 in the few years it has been hanging around. If there aren't going to be major discontinuous versions this is the way to go.
Of course, modern software outside shrink-wrap context is evermore incremental and pushed to the customer in small deltas. Even Windows now tells me it's a "service and regular updates are normal procedure".
But look at Chrome is on like version 70 in the few years it has been hanging around. If there aren't going to be major discontinuous versions this is the way to go.
My guess is because Linus has less than 2,019 fingers and toes...
<< ducks >>
<< ducks >>
Causing year 2119 problem for Linux?
Possibly because lots of software out there expects n.n(n) and not 20nn.n(n) ?
Wasn’t part of the reason behind the 2.6->3.0 change to help shatter some of those preconceived notions about version numbers?
Providing each year is a higher number than last year, why does it make it incompatible?
It just breaks existing regexes. When the kernel switched from 2.6.x.y to 3.x.y, it broke a lot of shoddy scripts that expected the version number to match e.g.
/^\d\.\d\.\d\.\d$/Are kernel maintainers responsible for shoddy scripts though?
At some point, I think so.
It's similar to a discussion I saw on here about Chrome adding a feature that you could use with a certain html attribute iirc, ie <div newattribute> or something.
Supposedly, nobody should have an attribute called 'newattribute' anywhere in their application, but that doesn't mean that there are is a non-zero amount of applications out there that do.
The problem is not so much that you can point and laugh at the crappy regexes, or crappy html-devs, the problem is that some scripts on some server, or some sites somewhere don't really have a maintainer anymore.
For tiny, tiny projects, you don't really have to take this into account, but if you're Chrome or the Linux kernel, you definitely should take it into account.
It's similar to a discussion I saw on here about Chrome adding a feature that you could use with a certain html attribute iirc, ie <div newattribute> or something.
Supposedly, nobody should have an attribute called 'newattribute' anywhere in their application, but that doesn't mean that there are is a non-zero amount of applications out there that do.
The problem is not so much that you can point and laugh at the crappy regexes, or crappy html-devs, the problem is that some scripts on some server, or some sites somewhere don't really have a maintainer anymore.
For tiny, tiny projects, you don't really have to take this into account, but if you're Chrome or the Linux kernel, you definitely should take it into account.
Linus has the (imho: valid) expectation that kernel changes should not break userspace (for detailed explanation see: https://unix.stackexchange.com/a/235532). Even if the version numbering is not an explicit API like say, file system drivers, the versioning of the kernel is an implicit guarantee that the kernel has made to userspace.
We had a turn of the century during Linux's life span, 1999-2000, which coincidentally was going to be a problem because so many computer systems used a two digit year.
So we have 80 years to solve the issue of supporting the version going from 99.X to 2100.1 :)
spoken like a true project manager
Now double that estimate, add some padding, and I am looking forward to the release of 2230.1
Throw in Windows XP becoming sentient and recreating the Windows Subsystem for Linux equivalent for Linux itself.
Good god man. What dark beasts lie in you.
I find it ridiculous people still cling to XP and IE, just wanted to poke fun. :)
But a 4 digit year as a version is ok, right?
19.1, 20.1
We can safely assume that for the next 80 or so years that the year will begin '20'.
That leaves 80+ years to patch the software that expects a certain version number format. Plenty of time.
We can safely assume that for the next 80 or so years that the year will begin '20'.
That leaves 80+ years to patch the software that expects a certain version number format. Plenty of time.
Who will stop us going from 99.nn to 100.nn?
As I said we have 80 years to patch the software.
The scheme was suggested to avoid a 20nn.n scheme that the parent identified.
Theres nothing to stop us from going from 99.nn to 100.nn and I wont be there to stop it. I'll remind my kids to point it out though :)
The scheme was suggested to avoid a 20nn.n scheme that the parent identified.
Theres nothing to stop us from going from 99.nn to 100.nn and I wont be there to stop it. I'll remind my kids to point it out though :)
"That will never be the case as long as humans are humans, 5.0 will mean something more than a decimal point update, even if the only difference is a couple of comment fixes and a regression in the MM" (me)
What is their problem for not simply following semver?
What would be a breaking change for Linux that would justify a major version increment? Linux doesn't break userspace, and there are no stable internal APIs or ABIs.
Also worth nothing that semver is a relatively recent phenomenon, at least as far as being articulated ideologically.
Kernel Newbies has a much more accessible summary than a git log. :)
https://kernelnewbies.org/Linux_5.0
https://kernelnewbies.org/Linux_5.0
I always wondered if in the far future there is a semantic wasteland waiting for apps that rapidly increase their version number. The difference between a version 65 and a version 66 is fairly manageable for average humans, just in terms of length of the number. But what about when comparing version 19753 and version 19754?
Windows (particularly during beta cycles) uses the build number as the version. They are usually things like '2574', and it never seemed a problem.
On the other hand, there was no continuous delivery - you were only receiving a subset of the builds (so maybe '2341' followed by '2784').
On the other hand, there was no continuous delivery - you were only receiving a subset of the builds (so maybe '2341' followed by '2784').
People need to stop thinking about version numbers as being something meaningful. Particularly in the era of package managers, CI pipelines and version pinning. eg many places would could use git commit hashes where the latest is pulled in by the CI pipeline for testing on the dev environments and then prod is version pinned to a specific hash until testing has vetted a newer commits as being safe for deployment.
edit: I'm curious why I'm getting so heavily down voted when the evidence is clearly there that the majority of projects versioning is completely arbitrary. Sure, there are some notable exceptions but when you're building complex secure systems you are often forced down the version pinning route with controlled and tested deployments for a great many software components.
edit: I'm curious why I'm getting so heavily down voted when the evidence is clearly there that the majority of projects versioning is completely arbitrary. Sure, there are some notable exceptions but when you're building complex secure systems you are often forced down the version pinning route with controlled and tested deployments for a great many software components.
> People need to stop thinking about version numbers as being something meaningful.
If they don't mean anything then get rid of them!
Of course they mean something. They (almost always) uniquely identify a particular release of the software. What do you use to do that instead?
If they don't mean anything then get rid of them!
Of course they mean something. They (almost always) uniquely identify a particular release of the software. What do you use to do that instead?
I can't tell if your comment is serious or not but in any case you're completely missed my point.
I'm talking about people who assume version 2.1 means something different from a version 1.2. Developers can bump version numbers in any which way they want and while some projects to have a documented standard for versioning; most projects do not. So consumers of software shouldn't base judgements solely on which digit is incremented in a version string.
I'm talking about people who assume version 2.1 means something different from a version 1.2. Developers can bump version numbers in any which way they want and while some projects to have a documented standard for versioning; most projects do not. So consumers of software shouldn't base judgements solely on which digit is incremented in a version string.
Bu9t if you know the project they can be meaningful. E.g. how many Rust libraries make a decent effort at following SemVer or how the two digits of PostgreSQL have very specific meanings which always are respected (the first digit is the major version which may contain new features and break APIs while the second digit is only for bugfixes and is not allowed to introduce any new feature).
The thing is, if you’re running production services, particularly ones that need to be stable and secure, then you need to treat any version update with caution; even point versions on SemVer strings. You’d still need to deploy to dev and test first, you’d still need to do any security scans you’d normally do, etc.
The dev community have suffered malware before from point releases being released by new authors. And we’ve seen occasions in the past where a bug fix in a point release has inadvertently broken something else.
I guess you can argue that SemVar gives you an estimate about the likelihood something will break which might help when estimating JIRA tickets for the next sprint. But realistically you’d still have to follow a cautious release cycle even for updating point releases when on production environments.
This is why I think we need to get past the mindset of treating version strings as something trustworthy. They offer no guarantees whatsoever.
The dev community have suffered malware before from point releases being released by new authors. And we’ve seen occasions in the past where a bug fix in a point release has inadvertently broken something else.
I guess you can argue that SemVar gives you an estimate about the likelihood something will break which might help when estimating JIRA tickets for the next sprint. But realistically you’d still have to follow a cautious release cycle even for updating point releases when on production environments.
This is why I think we need to get past the mindset of treating version strings as something trustworthy. They offer no guarantees whatsoever.
But it is useful as I can add something like implementation "io.springfox:springfox-swagger2:2.9.+" so that I can get all new point versions but nothing larger so that I don't risk a breaking change.
You cannot even guarantee point releases don't contain breaking changes. Nor can you assume they don't include new security vulnerabilities.
When deploying software in a production environment you should never deploy anything which hasn't first been tested through your CI pipeline and/or been through it's paces in your dev and test environments before deploying to prod.
In fact many engineers running on security systems will version lock even the point release for safety.
This is particularly true when working with smaller projects or packages in node / Go / whatever. In fact there was a case recently about someone who took ownership of a popular Python (I think it was) module, inserted malware and just upped the point release.
So in summary: no, you cannot even guarantee that point releases are safe.
When deploying software in a production environment you should never deploy anything which hasn't first been tested through your CI pipeline and/or been through it's paces in your dev and test environments before deploying to prod.
In fact many engineers running on security systems will version lock even the point release for safety.
This is particularly true when working with smaller projects or packages in node / Go / whatever. In fact there was a case recently about someone who took ownership of a popular Python (I think it was) module, inserted malware and just upped the point release.
So in summary: no, you cannot even guarantee that point releases are safe.
Version numbers certainly can be meaningful. They're frequently not used that way, but ex. semver is genuinely quite useful when people actually use it.
Sure, there will always be exceptions and I do agree that in those instances version numbering can be meaningful. However different projects follow different conventions and some projects don't even have a formal convention at all. So from a user perspective it's safer to assume no meaning for the majority of projects. Particularly when dealing with smaller community packages / modules pulled in from Puppet / npm / Go / whatever developer or DevOps tooling your project or business has adopted.
I'm really less concerned about larger projects like Apache which have a clear published versioning strategy because they're also the kind of projects that are less likely to bite you when doing what should be safe updates within minor / bugfix versions.
I'm really less concerned about larger projects like Apache which have a clear published versioning strategy because they're also the kind of projects that are less likely to bite you when doing what should be safe updates within minor / bugfix versions.
How about incrementing the version number by an amount proportional to the lines that have changed in the code base. So 10% of lines have changed and 20% of lines have been added, so increment version number from 5.6 to 7.28.
Lines of code are even less meaningful than version numbers.
There are some good standards out there for versioning. But honestly the best thing you can do as a developer or sysadmin is to treat every version update like a breaking change and run it through your dev and test environments before pushing to prod.
There are some good standards out there for versioning. But honestly the best thing you can do as a developer or sysadmin is to treat every version update like a breaking change and run it through your dev and test environments before pushing to prod.
What if you come up with a better algorithm for version 7.28 that is 80% shorter?
One of my favourite Apple history anecdotes:
https://www.folklore.org/StoryView.py?project=Macintosh&stor...
With my tongue firmly still in my cheek, I'd say increment the version number by the difference. So if you deduct 5% of the code and add another 15%, then increment the version number by 20%.
https://www.folklore.org/StoryView.py?project=Macintosh&stor...
With my tongue firmly still in my cheek, I'd say increment the version number by the difference. So if you deduct 5% of the code and add another 15%, then increment the version number by 20%.
Just use the absolute value. An 80% decrease is a big change just like an 80% increase.
(To be clear: I disagree with the suggestion, I just don't think this is a strong argument against it.)
(To be clear: I disagree with the suggestion, I just don't think this is a strong argument against it.)
I expect that sometime in the three-digit range projects will typically change to some other versioning scheme.
Seems like then the version numbers would become almost irrelevant. And that's what Chrome is gearing towards. The vast majority of people don't know which Chrome version there are running and they don't care because it auto-updates.
What the are the best resources for learning how the kernel currently works? I tried reading a bunch of O'reilly books on the subject, like device drivers, and the Love books, but they are all for 2.x kernels which are super ancient at this point.
Meanwhile on Redhat, still running on kernel 2.6.x
Things are about to double.
Things are about to double.
And another version that does not work out of the box for me... awesome. Need to wait till 6.0 to use this one.
From the above link (emphasize is mine)
> This release increases the major version number to 5. This change does not mean anything and does not affect programs in any way, it just makes Linus happy.
Oh...
> This release increases the major version number to 5. This change does not mean anything and does not affect programs in any way, it just makes Linus happy.
Oh...
I want linus to be happy! Don't you?
Gotta bump it sometime, although the fact that the major version is now fairly arbitrary gives some credibility to what I like to call the "Chrome" versioning scheme. Next release, Linux 6, 7, 8, etc.
EDIT: I mean, at this point I guess you'd say it's just basically SemVer.
EDIT: I mean, at this point I guess you'd say it's just basically SemVer.
> EDIT: I mean, at this point I guess you'd say it's just basically SemVer.
No, it specifically is not semver or indeed anything else meaningful.
No, it specifically is not semver or indeed anything else meaningful.
Link gives a 403
That's correct... they moved forward 398 major releases since the this article was released.
Archived link: http://archive.is/u325V
It seems to have been fixed now.
[deleted]
The entire Wikipedia section [1] dedicated to the history of the Linux kernel's versioning scheme is quite interesting.
A funny detail is that the 0.x version series progressed as 0.01, 0.02, 0.03, 0.10, 0.11, 0.12, 0.95, 0.96, 0.97, 0.98, and finally 0.99.
I found an archived message [2] from Linus dated 19 Dec '91 with a note about that jump directly from 0.12 to 0.95:
[2]: https://www.cs.cmu.edu/~awb/linux.history.html
A funny detail is that the 0.x version series progressed as 0.01, 0.02, 0.03, 0.10, 0.11, 0.12, 0.95, 0.96, 0.97, 0.98, and finally 0.99.
I found an archived message [2] from Linus dated 19 Dec '91 with a note about that jump directly from 0.12 to 0.95:
Note: The version number went directly from 0.12 to 0.95, as the
follow-on to 0.12 was getting feature-full enough to deserve a number
in the 0.90's
[2]: https://www.cs.cmu.edu/~awb/linux.history.html
Quote for those on mobile
Note: The version number went directly from 0.12 to 0.95, as the follow-on to 0.12 was getting feature-full enough to deserve a number in the 0.90's
Note: The version number went directly from 0.12 to 0.95, as the follow-on to 0.12 was getting feature-full enough to deserve a number in the 0.90's
The way I recall the story is that once X11 was running on Linux, Linus thought that he was nearly done and bumped the version number way up to 0.95. Then it turned out to take quite a lot more work to get stable, so 0.99 went up to "patchlevel 16z" or something.
Here's all the .99 versions: http://www.oldlinux.org/Linux.old/docs/history/0.99.html
Compare to earlier ones and you can see the reluctance to bump to 1.x
http://www.oldlinux.org/Linux.old/docs/history/0.98.html
Compare to earlier ones and you can see the reluctance to bump to 1.x
http://www.oldlinux.org/Linux.old/docs/history/0.98.html