The Community Really Wants To See Linux 4.0

[phoronix]

Phoronix: The Community Really Wants To See Linux 4.0

Linus Torvalds has yet to reveal whether Linux 3.20 will be re-branded as Linux 4.0, but it seems the community at least really wants this version bump to happen...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.0-Voting-56-44

[xeekei]

I would call 56% vs 44% as leaning a certain way, not "really wants".

[zanny]

I think it is incredibly stupid to have versoning that does not mean anything at all. When every other project in the universe either does major.minor.patch where major means backwards breaking changes, minor means non-breaking changes, and patch means security and bug fixes.

Linux mostly follows that, except as Linus says they will never break userspace (which I also disagree with, the kernel will turn into an NT like nightmare in 20 more years if you never break userspace to fix critical security vulnerabilities or colossal code rot of unused features) so the major version never has a reason to progress.

So why the hell not get rid of it? Make Linux minor.patch. There are other nomenclatures but you do need some versoning system for Linux that denotes both feature changes and security changes, because you always, no matter what, want the latest patch kernel, but may not want to adopt newer releases of the kernel.

But even the systemd "every version is an incremental number" makes more sense that a pointless major version. Throw a patch on the end and you have minor.patch. Or Ubuntu style time stamp releases, maybe with a patch on the end, like 2015-03.5 or something, though just incremental numbers are easier to understand.

But versioning that does not mean anything defeats the purpose of versioning. 3.0 was meaningful because it fixed the broken versioning from the 2.6 series. But 4.0 has no meaning at all, and I cannot fathom why everyone thinks its a great idea to make the major and minor version numbers mean nothing for the most free important software project in the world. How the hell is 20 too big of a number? What does that even mean, that you have released too many kernels? Is systemd 218 too much to comprehend, is that why nobody likes it?

[bpetty]

If there isn't going to be a set of major changes that drives up the major version, but just small incremental changes... I would be tempted to go the Ubuntu route and do "YY.MM". Many small incremental changes spanning multiple years renders your major version useless. You might as well keep it useful by letting it tell everyone when the thing was released.

[Creak]

If there isn't going to be a set of major changes that drives up the major version, but just small incremental changes... I would be tempted to go the Ubuntu route and do "YY.MM". Many small incremental changes spanning multiple years renders your major version useless. You might as well keep it useful by letting it tell everyone when the thing was released.

I also think the "YY.MM[.patch]" makes a lot of sense for Linux version system, since (as zanny said) Linux commits are made so it never breaks the userspace, so there will never be ground breaking changes and thus no major version bumps.
It is also very practical since it allows to easily now how old you kernel is.

[justmy2cents]

I also think the "YY.MM[.patch]" makes a lot of sense for Linux version system, since (as zanny said) Linux commits are made so it never breaks the userspace, so there will never be ground breaking changes and thus no major version bumps.
It is also very practical since it allows to easily now how old you kernel is.

i think month would be confusing a bit to track how much you're behind. not everyone knows release schedule

better would be year followed by yearly versions.

[Creak]

i think month would be confusing a bit to track how much you're behind. not everyone knows release schedule

better would be year followed by yearly versions.

Well I think that anyone interested in the Linux kernel knows that there is a version every two or three months.

[genstorm]

"Overwhelmingly"? 56% is not quite the landslide you're painting it as.

[duby229]

i think month would be confusing a bit to track how much you're behind. not everyone knows release schedule

better would be year followed by yearly versions.

I don't know. See lets just say hypothetically a kernel gets released on march 2015 as 15.03.0 The version number is obviously the date it was released and point number is obviously a release version.

That would work, but it breaks Linus' no big number rule.

[justmy2cents]

I don't know. See lets just say hypothetically a kernel gets released on march 2015 as 15.03.0 The version number is obviously the date it was released and point number is obviously a release version.

That would work, but it breaks Linus' no big number rule.

still, i wouldn't think year and big number would be confused. year is something people are used to.

bigger problem with month as second number would be "i want to roll back one release, where is the yy.m-1". speaking for me personally, i never liked ubuntu versioning. while year makes sense since it is consistent, skipping subversion number in order to specify month is not really making sense. makes rolling back lot more confusing

also, since 20 is already considered big number. wouldn't suggestion of 15.03.0 already impose temporary patch? what do you do in 5 years? adopt new versioning with year - 20?