Linus" Linus"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.
/^\d\.\d\.\d\.\d$/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 :)
What's wrong with simple monotonically increasing digits?
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.
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]
So:
2017.2018.39.332
<< ducks >>
Not that I disagree with your point though.
However talking about kernel maybe it isn't that much needed unless significant feature and breaking changes introduced.
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.
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.
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.