Live data from Hacker News

Linus Torvalds' poll about “big versions” in kernel releases

plus.google.com

1–10 of 70 posts

Re: Linus Torvalds' poll about “big versions” in kernel releases

#7
post #5

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.

Linux actually has/had flowery names: https://en.wikipedia.org/wiki/List_of_Linux_kernel_names

Re: Linus Torvalds' poll about “big versions” in kernel releases

#8
post #5

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.

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.

Re: Linus Torvalds' poll about “big versions” in kernel releases

#9
post #4

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 keep.

BTW; In a way the distributions already do a date based release. RHEL 6. RHEL6.1, RHEL6.2, etc.

Re: Linus Torvalds' poll about “big versions” in kernel releases

#10
post #4

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.

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 inevitably ships only minimal improvements.

I think feature-based is still the way to go, maybe there should be a regular discussion on what is "big enough" to grant a bump, done roughly every two or three years.

Post reply on HN