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.
What's wrong with simple monotonically increasing digits?
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.
[Year of Initial Release].[Year of incremental release].[week of incremental release].[Incremental Number]
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'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.
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.
Hopefully they'll future proof it, or they'll be cursing us come 9999.
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 :)
<< ducks >>
However talking about kernel maybe it isn't that much needed unless significant feature and breaking changes introduced.
Not that I disagree with your point though.
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.
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.
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.
These days KDE is amazingly stable, fast and feature-full. But the reputation and brand has not recovered from the 4.0 release yet.
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.
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  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
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
Compare to earlier ones and you can see the reluctance to bump to 1.x
> 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.
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.
On the other hand, there was no continuous delivery - you were only receiving a subset of the builds (so maybe '2341' followed by '2784').
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.
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.
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%.
(To be clear: I disagree with the suggestion, I just don't think this is a strong argument against it.)
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'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.
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.
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.
Things are about to double.