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.
Linus Torvalds' poll about “big versions” in kernel releases
11–20 of 70 posts
Re: Linus Torvalds' poll about “big versions” in kernel releases
#12This is one big bikeshedding.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#13Just 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.
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.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#14I wanted to vote, but no, can't do that without joining Google+ again, which I am emphatically against.
Of all social media platforms to vote on, the only one more closed than Google+ would have been Facebook.
Next time can we please use something like SurveyMonkey or Doodle (might not work for this) or ANYTHING but a f#$%ing social network that requires a login?
Re: Linus Torvalds' poll about “big versions” in kernel releases
#15Just 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.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#16Just 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.
If Linux used semantic versioning we'd be up to at least version 200.0 by now.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#17By 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…
That's a fair point that some distro shipping a 3-year-old kernel might look bad for PR purposes, even if it has patches backported.
Re: Linus Torvalds' poll about “big versions” in kernel releases
#18Why has he chosen Google+ of all places to hold this vote? I wanted to vote, but no, can't do that without joining Google+ again, which I am emphatically against. Of all social media platforms to vote on, the only one more closed than Google+ would have been Facebook. Next time can we please use something like SurveyMonkey or Doodle (might not work for this) or ANYTHING but a f#$%ing social network that requires a lo…
Re: Linus Torvalds' poll about “big versions” in kernel releases
#19Why has he chosen Google+ of all places to hold this vote? I wanted to vote, but no, can't do that without joining Google+ again, which I am emphatically against. Of all social media platforms to vote on, the only one more closed than Google+ would have been Facebook. Next time can we please use something like SurveyMonkey or Doodle (might not work for this) or ANYTHING but a f#$%ing social network that requires a lo…
Re: Linus Torvalds' poll about “big versions” in kernel releases
#20By 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.