11–20 of 53 posts
I went to see what the big changes were to justify a new major version number and saw: “The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0” I laughed out loud.
I can't help myself. I need to know why 5.0. Is there a reason, even a pointless one? Or is it truly a "just because" moment?
I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.
I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.
Although, if you change the time scales, maybe not so much: Kernels are released on a fairly-predictable cadence now, and patches come in (to the mailing list and maintainer trees) almost constantly. So, if this is as simple as extending timescales, that leads down to an impossible debate: What changes count as minor/major/patches? For example, some would say that adding a driver is just a patch (as it doesn't change other parts of the kernel); some would say that it is major (because it adds new functionality).
There's also the human element: If someone has something to contribute, they'll want discussion to start on it sooner rather than later. Also, rolling lots of major changes into a big release may make it hard to tease out bugs—and performance regressions—as the just-released major version makes its way down to individual distributions.
So in this case, I think the best think for your needs would be to ignore upstream kernels, and instead rely on a distro kernel: Pick whichever distro you think does kernels the best, and which uses a time-based release schedule, and use their kernel.
Or, get an LWN subscription, and keep an eye out for their regular "What's new in this kernel" articles.
I went to see what the big changes were to justify a new major version number and saw: “The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0” I laughed out loud.
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I went to see what the big changes were to justify a new major version number and saw: “The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0” I laughed out loud.
I can't help myself. I need to know why 5.0. Is there a reason, even a pointless one? Or is it truly a "just because" moment?
I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.
Coming up with a response to this one was harder than I expected. The calendar-based release cycle you describe is pretty different from what is practiced today. Although, if you change the time scales, maybe not so much: Kernels are released on a fairly-predictable cadence now, and patches come in (to the mailing list and maintainer trees) almost constantly. So, if this is as simple as extending timescales, that lea…
I went to see what the big changes were to justify a new major version number and saw: “The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0” I laughed out loud.
OK so Linus, like most, has 10 fingers and 10 toes: totaling 20.. Yet 4.21 was already assigned. What was the last thing he counted on? Guesses below.
Earlier quoted context omitted.
OK so Linus, like most, has 10 fingers and 10 toes: totaling 20.. Yet 4.21 was already assigned. What was the last thing he counted on? Guesses below.
whatever it was, he was using a lot of it back for the 1.3 series, which made it up to 1.3.100 at least.
I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.