31–40 of 70 posts
43% (3,687) I like big versions, and I cannot lie
57% (4,822) v4.0, 'cause I get confused easilyEarlier quoted context omitted.
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?
I can't believe there are so many critical security update that much often...
Just 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.
So what? 200 makes sense for software as old and consistently maintained as the Linux kernel. What is with the need of people to keep version numbers low?
Just 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.
This kind of comment just show ignorance. The kernel has been around for a few decades while semver has been around for what, 3 years now? Maybe it will adopt semver at some stage. I doubt it because the API is way too complex and broad to be covered in simple x.x.x notation, think of driver updates on vendors.
Earlier quoted context omitted.
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.
Earlier 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…
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..
I never understand why linux distributions download updates so often. I'd prefer something monthly at the most. I can't believe there are so many critical security update that much often...
By 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…
Just 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.
This kind of comment just show ignorance. The kernel has been around for a few decades while semver has been around for what, 3 years now? Maybe it will adopt semver at some stage. I doubt it because the API is way too complex and broad to be covered in simple x.x.x notation, think of driver updates on vendors.
That's irrelevant.
I doubt it because the API is way too complex and broad to be covered in simple x.x.x notation
They don't use that notation now?