This is one big bikeshedding.
Test
Linus Torvalds' poll about “big versions” in kernel releases
21–30 of 70 posts
Re: Linus Torvalds' poll about “big versions” in kernel releases
#22Just adopt semver. Stop romanticizing a version number. Give big releases a flowery names if that's important to you. Leave the version number as something with specific meaning.
Linux actually has/had flowery names: https://en.wikipedia.org/wiki/List_of_Linux_kernel_names
That page is almost as much fun as http://en.wikipedia.org/wiki/List_of_spacecraft_in_the_Cultu... .
Re: Linus Torvalds' poll about “big versions” in kernel releases
#23This is one big bikeshedding.
Yes, but it's his bike shed :-)
Re: Linus Torvalds' poll about “big versions” in kernel releases
#24Just adopt semver. Stop romanticizing a version number. Give big releases a flowery names if that's important to you. Leave the version number as something with specific meaning.
That only makes sense for projects that even try to maintain a stable API. Linux doesn't. If Linux used semantic versioning we'd be up to at least version 200.0 by now.
That really depends on the viewpoint. The user-space APIs are stable and the Kernel project is going great lengths to ensure that userspace is never broken (any breakage is treated as a bug).
So if you look at the userspace interface as the API semver would work against, we'd be at 1.0.1234 or something.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#25By his own admission, the first two numbers mean nothing. Kernel releases happen on a roughly regular schedule. Date-based versioning is clearly the correct answer and I don't know why it's never even discussed.
Linux people have a natural, inbuilt fear, of everything BSD related. Date based releases are evil! That's slightly a joke, but I think in reality the development model that Linus and the other maintainers have created are feature based more than timeline based. As a developer I would enjoy a date based release schedule. I don't follow HEAD closely anymore but it would be easier to keep up the general view I try to k…
I've seen Linus loose it with devs in the past for breaking backwards compatibility with kernel updates; I'd suggest this also has something to do with it -possibly more so than an inbuilt fear of BSD [1].
I'm failing to find an explanation of how the RHEL numbering scheme is date based -please could you expand?
[1] As a long term linux user, I have both fear and bafflement over BSD device naming and the lack of gnu options on standard utils ;)
Re: Linus Torvalds' poll about “big versions” in kernel releases
#26Earlier quoted context omitted.
If you mean having something like "2015.01.13", it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. If you mean bumping the major release number every N years, then you'd have people complaining when a "major" release inevi…
Yeah, I meant explicit dates in the version. The releases aren't feature-based now, and haven't been since like the 2.4 series, or maybe even earlier. They just merge whatever's ready, do a few months of testing and bugfixing, and release. The first two version numbers (3.x) are literally meaningless outside of identifying the particular set of merges that happened during the merge window. I think that'd be better re…
How about 2013.05.20__2014.02.13 for a kernel that was released in 2013 and last patched today?
Re: Linus Torvalds' poll about “big versions” in kernel releases
#27By his own admission, the first two numbers mean nothing. Kernel releases happen on a roughly regular schedule. Date-based versioning is clearly the correct answer and I don't know why it's never even discussed.
If you mean having something like "2015.01.13", it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. If you mean bumping the major release number every N years, then you'd have people complaining when a "major" release inevi…
It would make more sense to have 15.01, i.e. YY.MM.
Works perfectly fine for ubuntu and would likely not break the numbering scheme..
Re: Linus Torvalds' poll about “big versions” in kernel releases
#28By his own admission, the first two numbers mean nothing. Kernel releases happen on a roughly regular schedule. Date-based versioning is clearly the correct answer and I don't know why it's never even discussed.
Curious how/if Redhat would deal with date-based versioning. 2.6.32 was originally released ~6 years ago and for-better-for-worse their frequent security patching would make the original release date fairly irrelevant.
The problem with RHEL backporting security fixes (and Debian to a lesser extent) almost makes version numbering irrelevant too, though.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#29Just adopt semver. Stop romanticizing a version number. Give big releases a flowery names if that's important to you. Leave the version number as something with specific meaning.
Not sure whether semver makes sense at the kernel level. E.g. I was under the impression that maintaining drivers outside the kernel was a fool's errand because the interface keeps changing.
Imo the change of such an interface warrants a version bump . They should not be doing it often anyway. As a result this will reset the minor version number once in a while.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#30Just adopt semver. Stop romanticizing a version number. Give big releases a flowery names if that's important to you. Leave the version number as something with specific meaning.
Semver isn't the one and only way of versioning stuff. Heck, it's a pretty ridiculous model for projects that do releases based on time rather than features...
Sure, my point was not that semver is the best, my point was that version numbers aren't a product name, they should be scientific. Whether it's semver or date-based, as long as it obeys rules so that people using your product can easily distinguish versions.