"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.
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.
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?
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.
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.
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.
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.
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.
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).
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/
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.
> 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.
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.
"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)
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.
> 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.
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.
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?
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.
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.
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%.
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.
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.
