Linux 5.0 | Hacker News Reader

Linux 5.0

lore.kernel.org

331 pointsdoener86 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.

                Linus"

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.

That isn't versioning per se, that's just branding and marketing and bike shedding.

Not that I disagree with your point though.

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.

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?

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.

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?

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 :)

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. :)

spoken like a true project manager

But a 4 digit year as a version is ok, right?

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?

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.

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.

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.

Plenty of time, I suppose. But if history is anything to go by, you can be sure we'll wait until the last minute to start fixing old software.

Yes I was wondering whether to add a /s tag to that last sentence.

Hopefully they'll future proof it, or they'll be cursing us come 9999.

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 :)

Causing year 2119 problem for Linux?

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?

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.

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.

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

My guess is because Linus has less than 2,019 fingers and toes...

<< ducks >>

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.

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.

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.

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.

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

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.

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:

   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

[1]: https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

[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

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

https://kernelnewbies.org/LinuxChanges?rev1=371

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

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.

No, it specifically is not semver or indeed anything else meaningful.

I want linus to be happy! Don't you?

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.

5.0 changelog: https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/Change...

Kernel Newbies has a much more accessible summary than a git log. :)

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?

Just rebrand the product and then start again at 1.

You mean 'one'.

Chrome The First

Linu XI

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.

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.

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.

What if you come up with a better algorithm for version 7.28 that is 80% shorter?

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

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

> 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?

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.

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.

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.

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.

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').

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.

New features: https://www.phoronix.com/scan.php?page=article&item=linux-20...

Meanwhile on Redhat, still running on kernel 2.6.x

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.

Reply on news.ycombinator.com