First things first, I would like to know what prompted the change from
2.4 to 2.6 kernels. I know that the change had to do with the
development version, the 2.5 tree and the massive amounts of patches
distros had to carry. Aside from this i think it was also the
scheduler changes that prompted the 2.6 version, but I don't know all
that much about it and any other comments about the change would be
great.
Second I wanted to talk about the linux 2.7.x kernel, whats in the
making or maybe even not started, that could prompt a change to a 2.7
version kernel, i know that a lot of good changes are going into the
kernel as part of the rcX kernels in the 2.6 version. Would we
continue to see 2.6 kernels until some big problem shows its head and
we all go "oh sh**" and then change something so massive that it
prompts the change or are we going to continue with the 2.6 tree. I
just want to get some information and peoples opinions on this, just
to see where things are headed.
-Stoyan G
On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
>
> Second I wanted to talk about the linux 2.7.x kernel, whats in the
> making or maybe even not started
Nothing.
I'm not going back to the old model. The new model is so much better that
it's not even worth entertaining as a theory to go back.
That said, I _am_ considering changing just the numbering. Not to go back
to the old model, but because a constantly increasing minor number leads
to big numbers. I'm not all that thrilled with "26" as a number: it's hard
to remember.
So I would not dismiss (and have been thinking about starting) talk about
a simple numbering reset (perhaps yearly), but the old model of 3-year
developement trees is simply not coming back as far as I'm concerned.
In fact, I think the time-based releases (ie the "2 weeks of merge window
until -rc1, followed by roughly two months of stabilization") has been so
successful that I'd prefer to skip the version numbering model too. We
don't do releases based on "features" any more, so why should we do
version _numbering_ based on "features"?
For example, I don't see any individual feature that would merit a jump
from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
should be done by a time-based model too - matching how we actually do
releases anyway.
So if the version were to be date-based, instead of releasing 2.6.26,
maybe we could have 2008.7 instead. Or just increment the major version
every decade, the middle version every year, and the minor version every
time we make a release. Whatever.
But three-year development trees with a concurrent stable tree? Nope. Not
going to happen.
Linus
On Mon, Jul 14, 2008 at 9:22 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
>>
>> Second I wanted to talk about the linux 2.7.x kernel, whats in the
>> making or maybe even not started
>
> Nothing.
>
> I'm not going back to the old model. The new model is so much better that
> it's not even worth entertaining as a theory to go back.
I would also recomend staying away from the old model
>
> That said, I _am_ considering changing just the numbering. Not to go back
> to the old model, but because a constantly increasing minor number leads
> to big numbers. I'm not all that thrilled with "26" as a number: it's hard
> to remember.
The main reason I asked these questions is because we have 2.4.36 and
2.2.27 and those are pretty high numbers, so I thought maybe we would
start 2.7.x releases just so that they start back at 1
>
> So I would not dismiss (and have been thinking about starting) talk about
> a simple numbering reset (perhaps yearly), but the old model of 3-year
> developement trees is simply not coming back as far as I'm concerned.
>
> In fact, I think the time-based releases (ie the "2 weeks of merge window
> until -rc1, followed by roughly two months of stabilization") has been so
> successful that I'd prefer to skip the version numbering model too. We
> don't do releases based on "features" any more, so why should we do
> version _numbering_ based on "features"?
>
> For example, I don't see any individual feature that would merit a jump
> from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
> should be done by a time-based model too - matching how we actually do
> releases anyway.
Does it have to be even numbers only?
>
> So if the version were to be date-based, instead of releasing 2.6.26,
> maybe we could have 2008.7 instead. Or just increment the major version
> every decade, the middle version every year, and the minor version every
> time we make a release. Whatever.
I dont think people would agree with the 2008.7 version numbers
although it would make them more aware of how old the kernel and
prompt them to upgrade
>
> But three-year development trees with a concurrent stable tree? Nope. Not
> going to happen.
>
> Linus
>
On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
> >
> > For example, I don't see any individual feature that would merit a jump
> > from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
> > should be done by a time-based model too - matching how we actually do
> > releases anyway.
>
> Does it have to be even numbers only?
No. But the even/odd thing is still so fresh in peoples memory (despite us
not having used it for years), and I think some projects aped us on it, so
if I didn't change the numbering setup, but just wanted to reset the minor
number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
But I could also see the second number as being the "year", and 2008 would
get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
(and probably avoid the ".0" just because it again has the connotations of
a "big new untested release", which is not true in a date-based numbering
scheme). And then 2010 would be 3.0.1 etc..
Anyway, I have to say that I personally don't have any hugely strong
opinions on the numbering. I suspect others do, though, and I'm almost
certain that this is an absolutely _perfect_ "bikeshed-painting" subject
where thousands of people will be very passionate and send me their
opinions on why _their_ particular shed color is so much better.
The only thing I do know is that I agree that "big meaningless numbers"
are bad. "26" is already pretty big. As you point out, the 2.4.x series
has much bigger numbers yet.
And yes, something like "2008" is obviously numerically bigger, but has a
direct meaning and as such is possibly better than something arbitrary and
non-descriptive like "26".
Let the bike-shed-painting begin.
(I had planned on taking this up at the kernel summit, where the shed
painting is at least limited to a much smaller audience, but since you
asked..)
Linus
On Mon, 14 Jul 2008, Linus Torvalds wrote:
>> Does it have to be even numbers only?
>
> No. But the even/odd thing is still so fresh in peoples memory (despite us
> not having used it for years), and I think some projects aped us on it, so
> if I didn't change the numbering setup, but just wanted to reset the minor
> number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
>
> But I could also see the second number as being the "year", and 2008 would
> get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
> (and probably avoid the ".0" just because it again has the connotations of
> a "big new untested release", which is not true in a date-based numbering
> scheme). And then 2010 would be 3.0.1 etc..
Ok, I'll jump in.
I don't have strong feelings either, but I do have comments
1. for the historical reasons you allude to above going to a completely
different numbering system would be a nice thing
2. I do like involving the year, but I think 2008/2009/2010 are much
clearer then 2.8/2.9/3.0 let people shorten it verbally, but still realize
that it's a full year being referred to.
3. avoid using the month of the release (which ubuntu does), first you
aren't going to predict the month of relese ahead of time (so what will
the -rc's be called, the year is fairly clear and it's not _that_ bad if
2008.4 happens to come out in Jan 2009). also too many people don't
understand that 8.10 is between 8.9 and 8.11, not between 8.0 and 8.2
so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
David Lang
> Anyway, I have to say that I personally don't have any hugely strong
> opinions on the numbering. I suspect others do, though, and I'm almost
> certain that this is an absolutely _perfect_ "bikeshed-painting" subject
> where thousands of people will be very passionate and send me their
> opinions on why _their_ particular shed color is so much better.
>
> The only thing I do know is that I agree that "big meaningless numbers"
> are bad. "26" is already pretty big. As you point out, the 2.4.x series
> has much bigger numbers yet.
>
> And yes, something like "2008" is obviously numerically bigger, but has a
> direct meaning and as such is possibly better than something arbitrary and
> non-descriptive like "26".
>
> Let the bike-shed-painting begin.
>
> (I had planned on taking this up at the kernel summit, where the shed
> painting is at least limited to a much smaller audience, but since you
> asked..)
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, Jul 14, 2008 at 08:55:59PM -0700, [email protected] wrote:
> On Mon, 14 Jul 2008, Linus Torvalds wrote:
>
> >>Does it have to be even numbers only?
> >
> >No. But the even/odd thing is still so fresh in peoples memory (despite us
> >not having used it for years), and I think some projects aped us on it, so
> >if I didn't change the numbering setup, but just wanted to reset the minor
> >number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
> >
> >But I could also see the second number as being the "year", and 2008 would
> >get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
> >(and probably avoid the ".0" just because it again has the connotations of
> >a "big new untested release", which is not true in a date-based numbering
> >scheme). And then 2010 would be 3.0.1 etc..
>
> Ok, I'll jump in.
>
> I don't have strong feelings either, but I do have comments
>
> 1. for the historical reasons you allude to above going to a completely
> different numbering system would be a nice thing
>
> 2. I do like involving the year, but I think 2008/2009/2010 are much
> clearer then 2.8/2.9/3.0 let people shorten it verbally, but still realize
> that it's a full year being referred to.
>
> 3. avoid using the month of the release (which ubuntu does), first you
> aren't going to predict the month of relese ahead of time (so what will
> the -rc's be called, the year is fairly clear and it's not _that_ bad if
> 2008.4 happens to come out in Jan 2009). also too many people don't
> understand that 8.10 is between 8.9 and 8.11, not between 8.0 and 8.2
That's probably why openbsd jumps from 3.9 to 4.0. I like such a numbering
too. It compacts 3 numbers into 2 (like we had before) but without any
major/minor notion. You just bump each new version by 0.1 at a somewhat
regular rate. Having the year and a sub-version is fine too, but I think
it adds unnecessary digits. Or maybe jump to 8.X for 2008, then 9.X in
2009 and 10.X in 2010 ? That way, we have both the date and the simplicity.
And it's not like we really care about version 1000 in year 3000.
> so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
agreed, but with Y.r.s :-)
Willy
Willy Tarreau wrote:
> On Mon, Jul 14, 2008 at 08:55:59PM -0700, [email protected] wrote:
>> On Mon, 14 Jul 2008, Linus Torvalds wrote:
>>
>>>> Does it have to be even numbers only?
>>> No. But the even/odd thing is still so fresh in peoples memory (despite us
>>> not having used it for years), and I think some projects aped us on it, so
>>> if I didn't change the numbering setup, but just wanted to reset the minor
>>> number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
>>>
>>> But I could also see the second number as being the "year", and 2008 would
>>> get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
>>> (and probably avoid the ".0" just because it again has the connotations of
>>> a "big new untested release", which is not true in a date-based numbering
>>> scheme). And then 2010 would be 3.0.1 etc..
>> Ok, I'll jump in.
>>
>> I don't have strong feelings either, but I do have comments
>>
>> 1. for the historical reasons you allude to above going to a completely
>> different numbering system would be a nice thing
>>
>> 2. I do like involving the year, but I think 2008/2009/2010 are much
>> clearer then 2.8/2.9/3.0 let people shorten it verbally, but still realize
>> that it's a full year being referred to.
>>
>> 3. avoid using the month of the release (which ubuntu does), first you
>> aren't going to predict the month of relese ahead of time (so what will
>> the -rc's be called, the year is fairly clear and it's not _that_ bad if
>> 2008.4 happens to come out in Jan 2009). also too many people don't
>> understand that 8.10 is between 8.9 and 8.11, not between 8.0 and 8.2
>
> That's probably why openbsd jumps from 3.9 to 4.0. I like such a numbering
> too. It compacts 3 numbers into 2 (like we had before) but without any
> major/minor notion. You just bump each new version by 0.1 at a somewhat
> regular rate. Having the year and a sub-version is fine too, but I think
> it adds unnecessary digits. Or maybe jump to 8.X for 2008, then 9.X in
> 2009 and 10.X in 2010 ? That way, we have both the date and the simplicity.
> And it's not like we really care about version 1000 in year 3000.
I like the OpenBSD versioning as well. But they only have two releases a
year, so their number should grow slower. Using the same versioning to
linux will end up getting us to very large numbers that have no meaning.
It's basically the same as what's going on now.
I think using the year is the best idea. For instance, debian etch comes
with linux 2.6.18, it would be nice if the users could easily know how
old that actually is.
I think 8.X for 2008, 9.X for 2009 should be great. It's good enough so
none (or almost none) of us will live to see a need for changing it.
Assuming people from 2101 would rather see 1.X than 101.X. Anyhow, will
linux even survive that long with the same name, development model, etc?
Not very likely.
>> so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
>
> agreed, but with Y.r.s :-)
>
> Willy
>
On Tue, Jul 15, 2008 at 12:31 AM, Willy Tarreau <[email protected]> wrote:
> On Mon, Jul 14, 2008 at 08:55:59PM -0700, [email protected] wrote:
>> On Mon, 14 Jul 2008, Linus Torvalds wrote:
>>
>> >>Does it have to be even numbers only?
>> >
>> >No. But the even/odd thing is still so fresh in peoples memory (despite us
>> >not having used it for years), and I think some projects aped us on it, so
>> >if I didn't change the numbering setup, but just wanted to reset the minor
>> >number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
>> >
>> >But I could also see the second number as being the "year", and 2008 would
>> >get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
>> >(and probably avoid the ".0" just because it again has the connotations of
>> >a "big new untested release", which is not true in a date-based numbering
>> >scheme). And then 2010 would be 3.0.1 etc..
>>
>> Ok, I'll jump in.
>>
>> I don't have strong feelings either, but I do have comments
>>
>> 1. for the historical reasons you allude to above going to a completely
>> different numbering system would be a nice thing
>>
>> 2. I do like involving the year, but I think 2008/2009/2010 are much
>> clearer then 2.8/2.9/3.0 let people shorten it verbally, but still realize
>> that it's a full year being referred to.
>>
>> 3. avoid using the month of the release (which ubuntu does), first you
>> aren't going to predict the month of relese ahead of time (so what will
>> the -rc's be called, the year is fairly clear and it's not _that_ bad if
>> 2008.4 happens to come out in Jan 2009). also too many people don't
>> understand that 8.10 is between 8.9 and 8.11, not between 8.0 and 8.2
>
> That's probably why openbsd jumps from 3.9 to 4.0. I like such a numbering
> too. It compacts 3 numbers into 2 (like we had before) but without any
> major/minor notion. You just bump each new version by 0.1 at a somewhat
> regular rate. Having the year and a sub-version is fine too, but I think
> it adds unnecessary digits. Or maybe jump to 8.X for 2008, then 9.X in
> 2009 and 10.X in 2010 ? That way, we have both the date and the simplicity.
> And it's not like we really care about version 1000 in year 3000.
>
>> so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
>
> agreed, but with Y.r.s :-)
Interesting idea but that would still get us to the 20.1.5 and that
just seems really high, even if its based on year not on number of
releases. Although I still wanted to know about the original change
between 2.4 to 2.6 and what other then the version numbering prompted
the change
>
> Willy
>
>
-Stoyan
On Tuesday 2008-07-15 04:47, Linus Torvalds wrote:
>
>No. But the even/odd thing is still so fresh in peoples memory (despite us
>not having used it for years), and I think some projects aped us on it, so
>if I didn't change the numbering setup, but just wanted to reset the minor
>number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
Don't discriminate against odd numbers! :)
I always wanted to see a 2.<odd> on the mingetty login banner just
because that seemed cool, and to hopefully make the last people who
would say "but is not that development series?" finally get the
clue that Linux is not developed in that way anymore.
[in the previous to the previous mail]:
>We don't do releases based on "features" any more, so why should we do
>version _numbering_ based on "features"?
>
>For example, I don't see any individual feature that would merit a jump
>from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version
>jumps should be done by a time-based model too - matching how we
>actually do releases anyway.
Maybe not individual feature, but as a whole. We probably should have
jumped when the new model was introduced. Ok, that did not happen, but
over time, the kernel's abilities increased and then sometime, there
was a release where you would say (as of today) "yes, that kernel back
there has been a really good one" where a version jump would have been
warranted at the same time. For me, these are 2.6.18, .22, .23 or .25
(pick one). However, there also needs to be a bit of time between minor
number bumps, so if 2.6.18 were 2.7.0, 2.6.25 would be the earliest to
qualify for a 2.8.0.
My expectation is that 2.6.27 would be the next "good one" where a
version jump would go nicely in line. Make it 2.7.0, it got loads
of new features compared to 2.6.0 :)
My preference is of course that version numbers run at the same speed as
they have been for most of the time now - that is, incrementing the
micro as we go. If one were to increment the micro for every release
(2.6.18 -> 2.7, 2.6.19 -> 2.8, 2.6.20 -> 2.9) then that is a magnitude
higher and thus would count as faster-going.
>Anyway, I have to say that I personally don't have any hugely strong
>opinions on the numbering. I suspect others do, though, and I'm
>almost certain that this is an absolutely _perfect_
>"bikeshed-painting" subject where thousands of people will be very
>passionate and send me their opinions on why _their_ particular shed
>color is so much better.
>
>The only thing I do know is that I agree that "big meaningless numbers"
>are bad. "26" is already pretty big. As you point out, the 2.4.x series
>has much bigger numbers yet.
2.1.132 is big.
Numbering should be interesting and sometimes unexpected (like when
there suddently was a 2.<even>.0 announcement in my mailbox, or the
change of development model). The YYYY.r[.s] scheme defeats that, and
it counts fast too, though I am not opposed to YYYY.r.
What I am against is [YYYY-2008].r (8.0, 8.1, 9.0, etc.) since that may
be seen as a version number instead of the year.
On Mon, 2008-07-14 at 19:47 -0700, Linus Torvalds wrote:
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
> > > For example, I don't see any individual feature that would merit a jump
> > > from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
> > > should be done by a time-based model too - matching how we actually do
> > > releases anyway.
> >
> > Does it have to be even numbers only?
>
> No. But the even/odd thing is still so fresh in peoples memory (despite us
> not having used it for years), and I think some projects aped us on it, so
> if I didn't change the numbering setup, but just wanted to reset the minor
> number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
ACK. "Normal" users (and especially average journalists where most
"normal" users get their knowledge from) tend to know of "odd Linux
kernel version are development" (and will probably report it wrongly
that way if "2.7 is released").
Perhaps they learn the new model if 2.7 will never have existed and
people asked about.
[...]
> Anyway, I have to say that I personally don't have any hugely strong
> opinions on the numbering. I suspect others do, though, and I'm almost
> certain that this is an absolutely _perfect_ "bikeshed-painting" subject
ACK, probably the best. But others are surely better in proposing
beautiful colors.
[....]
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Linus Torvalds <[email protected]> writes:
>
> So if the version were to be date-based, instead of releasing 2.6.26,
> maybe we could have 2008.7 instead. Or just increment the major version
> every decade, the middle version every year, and the minor version every
> time we make a release. Whatever.
Or you could just do it like emacs or Solaris and simply use a single number.
-Andi
On Tuesday 2008-07-15 12:10, Andi Kleen wrote:
>Linus Torvalds <[email protected]> writes:
>>
>> So if the version were to be date-based, instead of releasing 2.6.26,
>> maybe we could have 2008.7 instead. Or just increment the major version
>> every decade, the middle version every year, and the minor version every
>> time we make a release. Whatever.
>
>Or you could just do it like emacs or Solaris and simply use a single number.
And both emacs and Solaris already have high numbers.
For the former that's probably warranted given its long existence.
Solaris, hm no, but the "SunOS 5.11" tag on the other hand,
is quite "acceptable".
Big numbers tend to be forgotten. Do you know offhand what the latest
MSOffice is? emacs? udev? less? I doubt you do.
My intuitive answers were:
12, 22, "somewhere in the 100s", "somewhere in the 400s".
Reality? I had to look up the last two.
12(.with.an.oodle.of.digits), 22.2, 124, 418/424(beta).
Maybe Linux would be different because you see the version on
some login prompts, dmesg, or similar.
On Mon, 2008-07-14 at 19:47 -0700, Linus Torvalds wrote:
>
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
> > >
<snip>
> Let the bike-shed-painting begin.
>
> (I had planned on taking this up at the kernel summit, where the shed
> painting is at least limited to a much smaller audience, but since you
> asked..)
I like the current numbering fine.. my suggestion is to keep the current
model, there are various reasons
1: it requires no effort
2: various things doesent break
3: naming isnt _THAT_ important
then you could increment the major number once something very important
happens, such as going to 2.8 when the removal of the BKL or something.
mvh.
Kasper Sandberg
On Mon, 14 Jul 2008, Linus Torvalds wrote:
> I think the time-based releases (ie the "2 weeks of merge window until -rc1,
> followed by roughly two months of stabilization") has been so successful that
> I'd prefer to skip the version numbering model too. We don't do releases
> based on "features" any more, so why should we do version _numbering_ based
> on "features"?
>
> For example, I don't see any individual feature that would merit a jump
> from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
> should be done by a time-based model too - matching how we actually do
> releases anyway.
>
> So if the version were to be date-based, instead of releasing 2.6.26,
> maybe we could have 2008.7 instead. Or just increment the major version
> every decade, the middle version every year, and the minor version every
> time we make a release. Whatever.
Well, we just haven't had anything big enough to merit an increase in the
minor number lately. I nominate the removal of the BKL as one such feature,
based on the sheer work required and how many modules you'll need to touch to
do so. In fact, it would be the natural conclusion to a 2.x series that
highlighted SMP as its primary new feature.
But it's hard now to predict future milestones, or when an overall paradigm
shift might happen. In those cases you'll want to give Linux a bright new
announcement to the world, instead of it being "just another standard year of
kernel development".
Remember, you used to have versions called 1.3.100 before -- and they seemed
perfectly normal back then. I personally like how we're still on 2.y.z numbers
compared to all of the other OSes (Solaris 11, HP-UX 11)...it makes Linux still
feel young, showing how much better it can get ;-)
So I vote for releasing by "features" still, and keep the current numbering
scheme. Who knows when the next big idea will pop up that's worthy of 3.0.0.
-Byron
[Linus Torvalds - Mon, Jul 14, 2008 at 07:22:04PM -0700]
|
|
| On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
| >
| > Second I wanted to talk about the linux 2.7.x kernel, whats in the
| > making or maybe even not started
|
| Nothing.
|
| I'm not going back to the old model. The new model is so much better that
| it's not even worth entertaining as a theory to go back.
|
| That said, I _am_ considering changing just the numbering. Not to go back
| to the old model, but because a constantly increasing minor number leads
| to big numbers. I'm not all that thrilled with "26" as a number: it's hard
| to remember.
|
| So I would not dismiss (and have been thinking about starting) talk about
| a simple numbering reset (perhaps yearly), but the old model of 3-year
| developement trees is simply not coming back as far as I'm concerned.
|
| In fact, I think the time-based releases (ie the "2 weeks of merge window
| until -rc1, followed by roughly two months of stabilization") has been so
| successful that I'd prefer to skip the version numbering model too. We
| don't do releases based on "features" any more, so why should we do
| version _numbering_ based on "features"?
|
| For example, I don't see any individual feature that would merit a jump
| from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
| should be done by a time-based model too - matching how we actually do
| releases anyway.
|
| So if the version were to be date-based, instead of releasing 2.6.26,
| maybe we could have 2008.7 instead. Or just increment the major version
| every decade, the middle version every year, and the minor version every
| time we make a release. Whatever.
|
| But three-year development trees with a concurrent stable tree? Nope. Not
| going to happen.
|
| Linus
|
Hi to all! Since I've been Cc'ed :) I think I'm not the right person
to be asked about numbering scheme (and since I'm not that long in
kernel) BUT actually I think there is only one question - it's not
about how to number the kernel but rather what we trying to say by
numbering scheme. Some areas should be distinguished:
- development/stable team
- distros
- regular users
Most developers work with git trees and rather carries about sha1 then
a version number :) So eventually numbering scheme is not that important
for developers by its own.
Distros - well, i think distros use they own scheme anyway so they don't
really care about kernel versioning scheme (Gentoo-2008, Fedora-9, Ubuntu-8.04...)
So we have the quite large group of people which should be considered for
convenient versioning scheme - _regular users_. Lets say I'm a regular user -
the most convenient scheme for me would be YYYY.r.s i think since it tells
me - this kernel is fresh enough to be used on my shining laptop, and maybe
it even supports all hardware I have! And at least it looks good -
Linux-2008.0.0
but personally i don't really care that much :)
- Cyrill -
On Tue, 15 Jul 2008, Andi Kleen wrote:
>
> Or you could just do it like emacs or Solaris and simply use a single number.
No, that would be horrible. The only point of changign the numbering would
be to make the numbers smaller. Not fewer. I don't like "26" much as a
version number, I'd like "131" even less.
So I'd much rather have something like "2.9.1" than "27", just because
it's a hierarchy of simpler numbers.
Linus
Andi Kleen <andi <at> firstfloor.org> writes:
> Or you could just do it like emacs or Solaris and simply use a single number.
No - because then those handful of Solaris supporters will get one more 'proof'
in support of their claims of Linux copying Solaris - first SystemTap copying
DTrace and now version numbers. See how we stand a risk of ending up convinced
we do not innovate?
On the other hand with Emacs style numbering - I am afraid Linus will be
severely tempted not to make a release in years or worse yet we would have a
rename on our hands - GNU/Emacs/Linux
So NAK on this one :) !
Parag
[Cyrill Gorcunov]
> Some areas should be distinguished:
Areas? "Target audience groups" maybe? Well, I'm also not a native
English writer ;-)
> - development/stable team
> - distros
> - regular users
> So we have the quite large group of people which should be considered for
> convenient versioning scheme - _regular users_. Lets say I'm a regular user -
> the most convenient scheme for me would be YYYY.r.s i think since it tells
> me - this kernel is fresh enough to be used on my shining laptop, and maybe
> it even supports all hardware I have! And at least it looks good -
> Linux-2008.0.0
So, the version numbers aren't important for anyone else than "regular
users"? Ok, I'm a "regular user", so then I'm qualified to comment
;-)
Microsoft has attempted using year numbers in their releases, do we
really want to go the same way? ;-) Well, indeed - my vote goes in the
direction of YYYY.r.s. I have one concern though, such a release
could easily be mistaken for beeing an actual date. Maybe better to
write 2008.r1.s1 to make it explicit it isn't the release date?
2008.r1.s1 would at a glance easily give me an impression on whether
the kernel version is "outdated", "mature" or "fresh". 2008.r1.s1 is
easily googlable (though googling for "linux changelog 2.6.25" isn't
really that difficult)
That being said, is it really reasonable to assume the linux kernel
will continue evolving gradually for all future? In all software,
sometimes it is really needed to make some major changes, break
backward compatibility and decrease the stability - and that's what
the major version numbers are for. I think saying "we'll never need
to change the major version number again" is roughly equivalent with
"the design of Linux 2.6 is perfect". Or, maybe some years or decades
down the road we'll all upgrade to something with a different name
than Linux ;-)
--
Tobias Brox, 69?42'N, 18?57'E
Linus Torvalds wrote:
>
> So if the version were to be date-based, instead of releasing 2.6.26,
> maybe we could have 2008.7 instead. Or just increment the major version
> every decade, the middle version every year, and the minor version every
> time we make a release. Whatever.
>
The Altera Quartus tool series have version 8.x for all the versions
released in 2008; they've followed that scheme since 2002. I think it
took until 2005 until anyone outside Altera noticed, but it was
reasonably clean. Presumably it will be 10.x in 2010.
Clearly, the 2. prefix has long outlived its usefulness as far as Linux
is concerned, and probably the 6 as well. I personally don't think
two-digit numbers are a big problem, although three-digit numbers *are*,
which is probably why a lot of software has x.xx format version identifiers.
-hpa
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
>>> For example, I don't see any individual feature that would merit a jump
>>> from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
>>> should be done by a time-based model too - matching how we actually do
>>> releases anyway.
>> Does it have to be even numbers only?
>
> No. But the even/odd thing is still so fresh in peoples memory (despite us
> not having used it for years), and I think some projects aped us on it, so
> if I didn't change the numbering setup, but just wanted to reset the minor
> number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
>
> But I could also see the second number as being the "year", and 2008 would
> get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
> (and probably avoid the ".0" just because it again has the connotations of
> a "big new untested release", which is not true in a date-based numbering
> scheme). And then 2010 would be 3.0.1 etc..
>
It occurred to me that another approach might make sense:
Linux was released in 1991 with a 1.0 in 1994, correct? So, why not make
1991 sort of the Linux Epoch? The major number would be the decade since
Linux' release (this being the second decade of Linux, it works well)
and the minor number could be the year within that decade of releases.
I like this idea personally because it doesn't break the current
numbering scheme (2.7 is still skipped, though) and it can be
self-consistent for a number of years. When Linux reaches its fifth
decade and its midlife crisis, it'll be in version 5.0.
I don't know. That's my shed's color. :)
> Anyway, I have to say that I personally don't have any hugely strong
> opinions on the numbering. I suspect others do, though, and I'm almost
> certain that this is an absolutely _perfect_ "bikeshed-painting" subject
> where thousands of people will be very passionate and send me their
> opinions on why _their_ particular shed color is so much better.
>
> The only thing I do know is that I agree that "big meaningless numbers"
> are bad. "26" is already pretty big. As you point out, the 2.4.x series
> has much bigger numbers yet.
>
> And yes, something like "2008" is obviously numerically bigger, but has a
> direct meaning and as such is possibly better than something arbitrary and
> non-descriptive like "26".
>
> Let the bike-shed-painting begin.
>
> (I had planned on taking this up at the kernel summit, where the shed
> painting is at least limited to a much smaller audience, but since you
> asked..)
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIfOcLi1yS1BuzIvgRAnW9AKCSBqFsctCS58XdZ81QdnSuMB4WpQCfbPTf
qTRm2dSF6OyvyTrN8cR4XzM=
=VcmW
-----END PGP SIGNATURE-----
On Mon, Jul 14, 2008 at 07:47:46PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
> > >
> > > For example, I don't see any individual feature that would merit a jump
> > > from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
> > > should be done by a time-based model too - matching how we actually do
> > > releases anyway.
> >
> > Does it have to be even numbers only?
>
> No. But the even/odd thing is still so fresh in peoples memory (despite us
> not having used it for years), and I think some projects aped us on it, so
> if I didn't change the numbering setup, but just wanted to reset the minor
> number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
>
> But I could also see the second number as being the "year", and 2008 would
> get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
> (and probably avoid the ".0" just because it again has the connotations of
> a "big new untested release", which is not true in a date-based numbering
> scheme). And then 2010 would be 3.0.1 etc..
>
> Anyway, I have to say that I personally don't have any hugely strong
> opinions on the numbering. I suspect others do, though, and I'm almost
> certain that this is an absolutely _perfect_ "bikeshed-painting" subject
> where thousands of people will be very passionate and send me their
> opinions on why _their_ particular shed color is so much better.
>...
The 2.6. prefix is like with X which is version 11 for 20 years and
still counting.
Or like with X11R6, that became X11R7 after 11 years, there might be in
a few years some big change that will warrant a 2.8 or 3.0 (the rewrite
of the kernel in Visual Basic .NET ;-) ).
But my personal opinion is that we now have an established version
numbering with the current development model that is 2.6.x, and users
got used to it.
If you'd change it you will only create confusion - e.g. with your 2.9.1
idea half the world will see that 9 is an odd number, remember the old
kernel versioning, and think this is the first development release
towards 3.0...
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On 15-07-08 20:04, H. Peter Anvin wrote:
> Clearly, the 2. prefix has long outlived its usefulness as far as Linux
> is concerned, and probably the 6 as well.
Been calling the -stable branches v20, v21, v22, ... here.
I do believe the numbering scheme should at least ostensibly still be
feature driven, not be a fully robotic date thing. With the latter, you
definitely miss out on press-opportunities and that's not even meant
cynical. There just is a bit of industry around Linux and the promotion
opportunities of (say) "Linux 3" are really lots, lots bigger than
anything boringly date based.
That even holds for things like books -- I just bet that a "all new,
covers Linux 3!" blurp on the cover sells lots more copies than a "all
new, covers the march 21st 2009 version of Linux!" one.
But yes, the current monotic increase is definitely getting a bit boring
as well. The kernel as of 2.6.26 is quite different from the kernel that
was known as 2.6.0 so just be creative I'd say and set a 2.8 goal. Next
version can be 2.9 (should be clear enough by then) and then watch world
domination happen with the big 3.0 release.
Linux 2010.5? Boooooooooring....
Rene.
Rene Herman wrote:
> On 15-07-08 20:04, H. Peter Anvin wrote:
>
>> Clearly, the 2. prefix has long outlived its usefulness as far as
>> Linux is concerned, and probably the 6 as well.
>
> Been calling the -stable branches v20, v21, v22, ... here.
>
> I do believe the numbering scheme should at least ostensibly still be
> feature driven, not be a fully robotic date thing. With the latter, you
> definitely miss out on press-opportunities and that's not even meant
> cynical. There just is a bit of industry around Linux and the promotion
> opportunities of (say) "Linux 3" are really lots, lots bigger than
> anything boringly date based.
And that's why after the adoption of generics and a few things java all
the sudden became java 5. I don't like that. I hope the world gets used
to learning things instead of just being driven by a pretty number. And
I think that not using marketing numbers on a popular software is a good
step into helping people realise that version numbers are meant to keep
track of the changes not to look cool.
> That even holds for things like books -- I just bet that a "all new,
> covers Linux 3!" blurp on the cover sells lots more copies than a "all
> new, covers the march 21st 2009 version of Linux!" one.
I rather just have good books around. I can bet that all -- or at least
most of -- those new "LINUX 3!" books would suck. So it's better if they
sell little or not sell at all.
> But yes, the current monotic increase is definitely getting a bit boring
> as well. The kernel as of 2.6.26 is quite different from the kernel that
> was known as 2.6.0 so just be creative I'd say and set a 2.8 goal. Next
> version can be 2.9 (should be clear enough by then) and then watch world
> domination happen with the big 3.0 release.
Well, if 2.6.0 was 3.0 (2003.0) then people would easily realise that
they're missing 5 years of kernel development. Given that hint, if they
take a look on a few Changelogs they'll soon find out they're missing on
quite a lot.
> Linux 2010.5? Boooooooooring....
Well, it is software versioning and not Gisele B?ndchen taking off her top.
> Rene.
On 16-07-08 08:55, Rafael C. de Almeida wrote:
> Rene Herman wrote:
>> I do believe the numbering scheme should at least ostensibly still be
>> feature driven, not be a fully robotic date thing. With the latter, you
>> definitely miss out on press-opportunities and that's not even meant
>> cynical. There just is a bit of industry around Linux and the promotion
>> opportunities of (say) "Linux 3" are really lots, lots bigger than
>> anything boringly date based.
>
> And that's why after the adoption of generics and a few things java all
> the sudden became java 5. I don't like that. I hope the world gets used
> to learning things instead of just being driven by a pretty number.
I don't. I hate bores.
More importantly though, that's really the kind of thing where you can
argue about how life should and/or could be until you're blue in the
face but if it isn't, it doesn't actually matter any. People intimately
involved with a project like Linux (say, subscribers to this list)
definitely look quite different at it than others and that's nothing
bad. Communicating information to these people through shortcuts like
version numbers isn't necesarily anything to avoid.
There ARE features in the pipeline you could plan for that would warrant
a version jump. I'd for example consider being able to run X not as root
a very worthy goal for a version jump (be it 2.8 or 3.0). That's also a
change in the area where those that are NOT intimately involved yet
interested in a more than professional way are -- on the desktop.
Really. I'd like it much better if the big cool feature of the all new
Linux kernel would be running X as user, rather than when the big cool
feature of X running as a user would require a version of Linux newer
than the february 2010 release.
If you get what I mean. Do trust me, you'll have time and opportunity
enough in your lifetime to be boringly professional.
Rene.
On 16-07-08 08:55, Rafael C. de Almeida wrote:
(and please don't drop CCs on linux-kernel. I for example in this case
would like the X as user thing to be noticed as I believe it's a nice
point as an "externally significant" thing)
> Rene Herman wrote:
>> I do believe the numbering scheme should at least ostensibly still be
>> feature driven, not be a fully robotic date thing. With the latter, you
>> definitely miss out on press-opportunities and that's not even meant
>> cynical. There just is a bit of industry around Linux and the promotion
>> opportunities of (say) "Linux 3" are really lots, lots bigger than
>> anything boringly date based.
>
> And that's why after the adoption of generics and a few things java all
> the sudden became java 5. I don't like that. I hope the world gets used
> to learning things instead of just being driven by a pretty number.
I don't. I hate bores.
More importantly though, that's really the kind of thing where you can
argue about how life should and/or could be until you're blue in the
face but if it isn't, it doesn't actually matter any. People intimately
involved with a project like Linux (say, subscribers to this list)
definitely look quite different at it than others and that's nothing
bad. Communicating information to these people through shortcuts like
version numbers isn't necesarily anything to avoid.
There ARE features in the pipeline you could plan for that would warrant
a version jump. I'd for example consider being able to run X not as root
a very worthy goal for a version jump (be it 2.8 or 3.0). That's also a
change in the area where those that are NOT intimately involved yet
interested in a more than professional way are -- on the desktop.
Really. I'd like it much better if the big cool feature of the all new
Linux kernel would be running X as user, rather than when the big cool
feature of X running as a user would require a version of Linux newer
than the february 2010 release.
If you get what I mean. Do trust me, you'll have time and opportunity
enough in your lifetime to be boringly professional.
Rene.
On Tuesday 2008-07-15 22:43, Adrian Bunk wrote:
>
>The 2.6. prefix is like with X which is version 11 for 20 years and
>still counting.
>
>Or like with X11R6, that became X11R7 after 11 years, there might be
>in a few years some big change that will warrant a 2.8 or 3.0 (the
>rewrite of the kernel in Visual Basic .NET ;-) ).
Jumping the major number would really require some big flag day.
What was it that made the jump from 1.x to 2.0?
(Some ABI change w.r.t. binaries -- ELF becoming standard maybe?)
On 16-07-08 09:53, Jan Engelhardt wrote:
> On Tuesday 2008-07-15 22:43, Adrian Bunk wrote:
>> The 2.6. prefix is like with X which is version 11 for 20 years and
>> still counting.
>>
>> Or like with X11R6, that became X11R7 after 11 years, there might be
>> in a few years some big change that will warrant a 2.8 or 3.0 (the
>> rewrite of the kernel in Visual Basic .NET ;-) ).
>
> Jumping the major number would really require some big flag day.
> What was it that made the jump from 1.x to 2.0?
> (Some ABI change w.r.t. binaries -- ELF becoming standard maybe?)
SMP support.
Rene
In article <[email protected]> Renewrote:
> I do believe the numbering scheme should at least ostensibly still be
> feature driven, not be a fully robotic date thing. With the latter, you
2.6.9 was the last of a sequence of internally compatible kernels.
2.6.16 or 18 or 22 is the last of another such sequence (depending on
what you look at)
2.6.24 probably should have started a new version number.
Peter
On Tue, Jul 15, 2008 at 12:10:09PM +0200, Andi Kleen wrote:
> Or you could just do it like emacs or Solaris and simply use a single number.
Oh just like 'less'. I currently have version 418 of less installed it
would seem.
--
Len Sorensen
On Tue, Jul 15, 2008 at 10:07:21AM -0400, Byron Stanoszek wrote:
> Well, we just haven't had anything big enough to merit an increase in the
> minor number lately. I nominate the removal of the BKL as one such feature,
> based on the sheer work required and how many modules you'll need to touch
> to
> do so. In fact, it would be the natural conclusion to a 2.x series that
> highlighted SMP as its primary new feature.
>
> But it's hard now to predict future milestones, or when an overall paradigm
> shift might happen. In those cases you'll want to give Linux a bright new
> announcement to the world, instead of it being "just another standard year
> of
> kernel development".
>
> Remember, you used to have versions called 1.3.100 before -- and they seemed
> perfectly normal back then. I personally like how we're still on 2.y.z
> numbers
> compared to all of the other OSes (Solaris 11, HP-UX 11)...it makes Linux
> still
> feel young, showing how much better it can get ;-)
>
> So I vote for releasing by "features" still, and keep the current numbering
> scheme. Who knows when the next big idea will pop up that's worthy of 3.0.0.
Didn't HP-UX 11 come out around a decade ago? Did they stop
development?
--
Len Sorensen
* Lennart Sorensen <[email protected]>:
>
> Didn't HP-UX 11 come out around a decade ago? Did they stop
> development?
The short answer is that HP-UX decided to keep major number 11 as
a branding decision, and has released updates such as 11i, 11i v1,
11i v2, etc.
Most recent release was 11i v3, and if you do a uname -a, you'll
see that you get a "real" version, like 11.31.
http://en.wikipedia.org/wiki/Hpux#Versions
/ac
On Wed, Jul 16, 2008 at 06:03:01PM -0600, Alex Chiang wrote:
> The short answer is that HP-UX decided to keep major number 11 as
> a branding decision, and has released updates such as 11i, 11i v1,
> 11i v2, etc.
>
> Most recent release was 11i v3, and if you do a uname -a, you'll
> see that you get a "real" version, like 11.31.
So the 11 no longer has any meaning. At least when Sun decided the 5 in
SunOS Version 5.x didn't have a meaning anymore, they dropped it. Of
course sun also called it solaris 2.x at the same time as SunOS 5.x, so
perhaps dropping everything but the x made sense.
Version numbers never stay the way they were intended to.
--
Len Sorensen
On Tuesday 2008-07-15 09:49, Jan Engelhardt wrote:
>Sometime on Tuesday 2008-07-15, Linus Torvalds wrote:
>
>>We don't do releases based on "features" any more, so why should we do
>>version _numbering_ based on "features"?
>>
>>For example, I don't see any individual feature that would merit a jump
>>from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version
>>jumps should be done by a time-based model too - matching how we
>>actually do releases anyway.
>
>Maybe not individual feature, but as a whole. We probably should have
>jumped when the new model was introduced. Ok, that did not happen, but
>over time, the kernel's abilities increased and then sometime, there
>was a release where you would say (as of today) "yes, that kernel back
>there has been a really good one" where a version jump would have been
>warranted at the same time. For me, these are 2.6.18, .22, .23 or .25
>(pick one). However, there also needs to be a bit of time between minor
>number bumps, so if 2.6.18 were 2.7.0, 2.6.25 would be the earliest to
>qualify for a 2.8.0.
Continuing on that thought..
Incrementing the minor number once every 6 to 8 releases or so
(resetting the micro number to 0 of course) would nicely mark a group
of featureful kernels.
On Tue, 15 Jul 2008 15:27:56 +0000 (UTC)
Parag Warudkar <[email protected]> wrote:
> Andi Kleen <andi <at> firstfloor.org> writes:
>
>
> > Or you could just do it like emacs or Solaris and simply use a single number.
>
> No - because then those handful of Solaris supporters will get one more 'proof'
> in support of their claims of Linux copying Solaris - first SystemTap copying
> DTrace and now version numbers. See how we stand a risk of ending up convinced
> we do not innovate?
"Support" - dtrace is based on the IBM work it seems, and the IBM work
predates Solaris dtrace by a long time, so actually you could argue
Solaris copied Linux but shipped first ;)
> maybe we could have 2008.7 instead. Or just increment the major version
> every decade, the middle version every year, and the minor version every
> time we make a release. Whatever.
Why 2008 ? We have lots of year systems beyond the specific Western one.
Surely "38." as the Unix epoch time...
And .. 2008 sounds so "old Windows numbering"
* Lennart Sorensen <[email protected]>:
> On Wed, Jul 16, 2008 at 06:03:01PM -0600, Alex Chiang wrote:
> > The short answer is that HP-UX decided to keep major number 11 as
> > a branding decision, and has released updates such as 11i, 11i v1,
> > 11i v2, etc.
> >
> > Most recent release was 11i v3, and if you do a uname -a, you'll
> > see that you get a "real" version, like 11.31.
>
> So the 11 no longer has any meaning.
Not exactly. The 11 implies an ABI/API guarantee to ISVs and some
sense of "stability" (for whatever that means) to end users.
Marketing fluff, yes, but I guess some people out there do care
about that stuff.
/ac
Use 2.8 in 2008, 2.9 in 2009, 2.10 in 2010, etc?
Craig Milo Rogers
On Thursday 2008-07-17 21:56, Craig Milo Rogers wrote:
> Use 2.8 in 2008, 2.9 in 2009, 2.10 in 2010, etc?
>
> Craig Milo Rogers
>
Follow the thread. :)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forgive me if I missed it, but I've not seen any suggestions along the lines
of this: how about just dropping the now-meaningless '.6' from the version
string and retaining the rest. In other words:
2.27
2.27.1
...
2.28
2.28.1
2.28.2
That way you continue the series in a meaningful way, whilst reverting to a
neater 3-level numbering scheme again. Perhaps you could make 2.[6.]30 the
switchover point....
Cheers
AL
- --
====================================================================
ALASTAIR STEVENS
* Web - http://www.altrux.me.uk
* Blog - http://www.altrux.me.uk/blog.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIf8ITxW64B3bJb+wRAlxMAJ0cRiRBeN2MVBxauLudZDBQ9mEjEACfVx0C
kNjXCycMZ+rxLvoMIVh0EAY=
=04yz
-----END PGP SIGNATURE-----
Another point that came into my mind:
How many scripts and programs out there parse the kernel version number,
know about the 2.6 prefix, and might need an update if it changes?
Not a big deal if a change would indicate a big change like with the old
development model - but IMHO not worth it if there's no compelling
reason why we have to change the numbering at all.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Jul 17, 2008 at 11:05:07PM +0100, Alastair Stevens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Forgive me if I missed it, but I've not seen any suggestions along the lines
> of this: how about just dropping the now-meaningless '.6' from the version
> string and retaining the rest. In other words:
>
> 2.27
> 2.27.1
> ...
> 2.28
> 2.28.1
> 2.28.2
>
> That way you continue the series in a meaningful way, whilst reverting to a
> neater 3-level numbering scheme again. Perhaps you could make 2.[6.]30 the
> switchover point....
So what makes the 6 meaningless and the 2 meaningful and worth keeping?
It does nothing for Linus's dislike of large numbers either.
--
Len Sorensen
In article <[email protected]> Lennart wrote:
> On Thu, Jul 17, 2008 at 11:05:07PM +0100, Alastair Stevens wrote:
>> Forgive me if I missed it, but I've not seen any suggestions along the lines
>> of this: how about just dropping the now-meaningless '.6' from the version
>> string and retaining the rest. In other words:
>>
>> 2.27
>> 2.27.1
>> ...
>> 2.28
>> 2.28.1
>> 2.28.2
>>
>> That way you continue the series in a meaningful way, whilst reverting to a
>> neater 3-level numbering scheme again. Perhaps you could make 2.[6.]30 the
>> switchover point....
> So what makes the 6 meaningless and the 2 meaningful and worth keeping?
Nothing. Drop both.
2.6.28 -> 2.8.0
could be a useful switch point.
> It does nothing for Linus's dislike of large numbers either.
The above does.
Peter
Alan Cox <[email protected]> writes:
> On Tue, 15 Jul 2008 15:27:56 +0000 (UTC)
> Parag Warudkar <[email protected]> wrote:
>
>> Andi Kleen <andi <at> firstfloor.org> writes:
>>
>>
>> > Or you could just do it like emacs or Solaris and simply use a single number.
>>
>> No - because then those handful of Solaris supporters will get one more 'proof'
>> in support of their claims of Linux copying Solaris - first SystemTap copying
>> DTrace and now version numbers. See how we stand a risk of ending up convinced
>> we do not innovate?
>
> "Support" - dtrace is based on the IBM work it seems, and the IBM work
> predates Solaris dtrace by a long time, so actually you could argue
> Solaris copied Linux but shipped first ;)
Actually SLES9 shipped with IBM dprobes[1] long before Solaris dtrace even
existed (and OS/2 did long before that). Back then the interest in it
was about zero though, which made SLES10 drop it again.
I think I was one of the very few users. Admittedly the early RPN
probes were also not particularly user friendly, but they worked.
I use this always as an example that even sophisticated users
like system administrators and kernel hackers are somewhat marketing driven.
-Andi
[1] which BTW already supported user space probes
On Tuesday 15 July 2008, Kasper Sandberg wrote:
> I like the current numbering fine.. my suggestion is to keep the current
> model, there are various reasons
>
> 1: it requires no effort
> 2: various things doesent break
> 3: naming isnt _THAT_ important
Sorry for entering a discussion from a project I'm just a user of, but I was
thinking... I do see smallish problems with current scheme:
- First two numbers never change (2.6), so they're mostly useless.
- Third number gets too big (currently 26, and growing)
- Stable releases are already a fourth number (2.6.25.11. Unconfortable).
So a possible solution that would not break completely with historical numbers
could be:
- Since you're aproaching 2.6.30 (around mid 2009), why not agree tu turn that
into a 3.0 release? Peope have been expecting a version 3 of the kernel for a
long time now... It might give the (false) impression that it's an all new
release, but it would be explained that it's just a normal one. However, I
also think that by that time, the last "problem" with Linux will be solved,
i.e, the graphics thing. With the changes in DRM/DRI starting to appear in
2.6.27 (maybe), they will stabilize through .28 and .29, making .30 a good
release to declare the Linux kernel "completely mature", without any weak
spot (so to say) and turn it into 3.0 release (the Free drivers for ATI and
even NVIDIA will hopefully be mature by then too, as might be Gallium3D,
VA-API, GEM/TTM, etc... )
- From there, how to proceed? Instead of making the same mistake again of
having a useless middle number, each release would increment by a 10th. That
is, instead of 3.0.1, 3.0.2, etc... just 3.1, 3.2, 3.3, etc... Then the stable
releases would be 3.1.1, 3.1.2, etc... (no longer a 4 series of numbers). And
after 3.9, we would have 4.0 to avoid having again a too bit number (3.26,
etc...). Roughly, you release 5 kernels per year, so that would give enough
time until you hit a high number (it will increment by one every two years).
For example, it would take 20 years from 2009 until you hit version 13.0.
Twenty years is a decent amount of time in kernel development. And well, even
13 is not _that_ big anyway. You can push this numbering up to version 20 if
necessary and that would give another 14 extra years. By then (year 2043) I'm
sure that someone will have come up with a smart way of rearranging the
numbering once more :-)
Regards.
On 08.07.17, Jan Engelhardt wrote:
> On Thursday 2008-07-17 21:56, Craig Milo Rogers wrote:
>
> > Use 2.8 in 2008, 2.9 in 2009, 2.10 in 2010, etc?
>
> Follow the thread. :)
Actually, I did, which was why I thought my succinct sequence
was sufficient. Here's what I meant to convey, in words: use the
millennium as the major version number, the year-of-millennium as the
minor version number, and (by implication) the usual release and
stable suffixes.
This sequence had not been proposed yet in the thread, perhaps
for some reason like it's a stupid idea, since it will soon violate the
largish meaningless number rule in the year-of-millennium.
In case you think I'm mistaken in my assertation that it
hasn't been proposed before in the thread, the rest of this message
summarizes the pertinent posts in the thread:
In <[email protected]>,
Linus Torvalds proposed two possible new patterns:
yyyy.month
decade.year.release
In <[email protected]>,
Linus Torvalds proposed this pattern:
2.8.release in 2008, 2.9.release in 2009, 3.0.release in 2010
Linux also expressed a dislike for large, meaningless numbers.
In <alpine.DEB.1.10.0807142048260.6370@asgard>, David Lang expressed a
preference for yyyy.release, and expressed a dislike for yyyy.month on
two grounds: 1) it's hard to predict the release month, so how should
the -rc's be named, and 2) some people don't understand that 8.10
comes after 8.9. He then proposed:
yyyy.r.s (r=release, s=stable, as at present)
In <[email protected]>, Willy Tarreau proposed:
y.r.s (y = yyyy - 2000), e.g. use 9.r.s in 2009, 10.r.s in 2010
In <[email protected]>, Rafael C. de Almeida seconded 8.x,
9.x, 10.x, and commented that neither Linux nor any of us would live
long enough to worry about 101.x. [I eschew such pessimism. :-)]
There were some comments that didn't propose alternative sequences
(which I may skip mentioning from here on), then in
<[email protected]> Andi Kleen proposed using a single
number like Solaris.
In <[email protected]>, Alan Cox commented
that 2008 is specific to a particular Western calendar (which leads to
amusing trains of thought about Linux having different version numbers
in countries that have different calendars. Version number locale,
anyone?). He proposed Unix epoch time: 38.x
In <1216125715.10312.4.camel@localhost>, Kasper Sandberg said he likes
the current system, with the major number changing when something
important happens. [He didn't define "important".]
In <[email protected]>, Kasper Sandberg proposed
avoiding largish numbers for a while by going to 3.0 in 2009, then
incrementing releases by a tenth, with the stable version coming after
that:
3.1.x, 3.2,x, ... 3.9.x, 4.0.x
In <[email protected]>, Tobias Brox proposed:
YYYY.r#.s# (meaning that the letter "r" would preceed the relese number, and
the letter "s" would preceed the stable number)
In <[email protected]>, Charles grey wolf Banas proposed
using a Linux epoch decade as the first number, with the minor number
being the year in that decade. I think this is the same as the y.r.s
proposal, except maybe off by one, given that Linux was first released
in 1991 and not 1990.
In <[email protected]>, Rene Herman proposed [somewhat
arbitrary] transition to 2.8 and 2.9, and specified that 3.0 should be
until when world domination by Linux is near.
There were discussions about feature-based numbering. In
<[email protected]>,
Adrian Bunk suggested that the major number should jump whenever there
was a big flag day.
In <[email protected]>,
Jan Engelhardt proposed the rule that the minor version number should
be incremented every 6 to 8 releases, within the current scheme.
In <[email protected]>, Craig Milo Rogers proposed using
the millenium as the major version and the year-of-millennium as the
minor version, with the implcation that they would be followed by the
usual release and stable numbers. The main disadvantage of this
proposal, as I see it, is it will suffer the "largish meaningless
number" problem in another decade or two.
In <[email protected]>, Alastair Stevens proposed dropping
the ".6" and proceeding with a three-level numbering scheme:
2.6.26.s, 2.27.s, 2.28.s, ...
In <[email protected]>, Peter T. Breuer
proposed switching to a three-level numbering scheme and resetting the
middle number when useful [which I suppose might mean a major feature
change or just a desire to avoid largish meaningless numbers]. I
assume this sould give a sequence like:
2.6.26.s, 2.8.s, 2.9.s, 2.10.s,
Craig Milo Rogers
On 19-07-08 10:00, Craig Milo Rogers wrote:
> In <[email protected]>, Rene Herman proposed [somewhat
> arbitrary] transition to 2.8 and 2.9, and specified that 3.0 should
> be until when world domination by Linux is near.
Nonono, that's all backwards! This is about having a 3.0 release BRING
ABOUT world domination!
</tongue in cheek> and all but that was my point -- with a not at least
ostensibly feature driven scheme you loose out on all the hype, press,
marketing and, frankly, on the fun.
Really, find me a single Linux developer who wouldn't try just a little
bit harder for a big 3.0 release. This is still a community, not yet a
boring office schedule...
Rene.
In article <[email protected]> you wrote:
> In <[email protected]>, Peter T. Breuer
> proposed switching to a three-level numbering scheme and resetting the
> middle number when useful [which I suppose might mean a major feature
> change or just a desire to avoid largish meaningless numbers]. I
> assume this sould give a sequence like:
> 2.6.26.s, 2.8.s, 2.9.s, 2.10.s,
Actually he said
rename 2.6.28 to 2.8.0
or
rename 2.6.29 to 2.9.0
or
rename 2.6.30 to 3.0.0
i.e. .. whatever you are doing now, just drop the first two numbers (the
"2.6" bit) since they seem to be constant.
I don't know where the idea you propose above came from, and I don't
quite understand it either!
Remember that Linus' only objective is to have smaller numbers, which
may therefore
1) be memorable
2) be good advertising copy
3) be meaningful
and that was the only intention of my scheme: "drop the constant bit".
Peter
On 08.07.19, Rene Herman wrote:
> Really, find me a single Linux developer who wouldn't try just a little bit
> harder for a big 3.0 release. This is still a community, not yet a boring
> office schedule...
I'm afraid that the allure of 3.0 would mean that everyone
would want to get their shiny new subsystem/scheduler
rewrite/bootstrap file format change/whatever incorporated into it,
resulting in a protracted integration period and an unstable system.
According to this line of thought, Linus should simply announce
version 3.0 with no forewarning...
Craig Milo Rogers
On Sat, 19 Jul 2008, Craig Milo Rogers wrote:
> On 08.07.19, Rene Herman wrote:
>> Really, find me a single Linux developer who wouldn't try just a little bit
>> harder for a big 3.0 release. This is still a community, not yet a boring
>> office schedule...
>
> I'm afraid that the allure of 3.0 would mean that everyone
> would want to get their shiny new subsystem/scheduler
> rewrite/bootstrap file format change/whatever incorporated into it,
> resulting in a protracted integration period and an unstable system.
> According to this line of thought, Linus should simply announce
> version 3.0 with no forewarning...
not to mention that people would avoid it becouse it would be a .0 release
and therefor perceived as being unstable (and for the reasons that Craig
lists, they would probably be right)
David Lang
On 08.07.19, Peter T. Breuer wrote:
> In article <[email protected]> you wrote:
> > In <[email protected]>, Peter T. Breuer
> > proposed switching to a three-level numbering scheme and resetting the
> > middle number when useful [which I suppose might mean a major feature
> > change or just a desire to avoid largish meaningless numbers]. I
> > assume this sould give a sequence like:
>
> > 2.6.26.s, 2.8.s, 2.9.s, 2.10.s,
>
> Actually he said
>
> rename 2.6.28 to 2.8.0
> or
> rename 2.6.29 to 2.9.0
> or
> rename 2.6.30 to 3.0.0
>
> i.e. .. whatever you are doing now, just drop the first two numbers (the
> "2.6" bit) since they seem to be constant.
So you're saying that the formula is to drop the "2.6" and place
a period between the first and sedond digits of what's currently the
release number? OK, I hadn't interpreted it that way. Does the sequence
continue like this?
... 9.9.0, 10.0.0, ...
> Remember that Linus' only objective is to have smaller numbers, which
> may therefore
>
> 1) be memorable
> 2) be good advertising copy
> 3) be meaningful
>
> and that was the only intention of my scheme: "drop the constant bit".
And the underlying problem is that there are only so many
small numbers. Eventually, inevitably, constant bits accumulate in
front of the changing bits.
Given the three criteria shown above, Linus' proposed scheme:
yyyy.r.s
seems best to me. We know the year, it relates directly to common
experience and effectively is a small number (this year, last year,
two years ago... 0, 1, 2 years ago).
There's the potential for cognitive dissonance if the linux
kernel takes a yyy.x format and the distrbutions also use yyyy.x, but
the two aren't the same? e.g., what will people think if, say,
openSUSE 2009.2 contains linux kernel 2009.1? Perhaps the
distibutions would synchronize to kernel releases as a consequence of
a revised kernel naming convention?
There's the question of what to do if you plan on a end-of year
release, and it just doesn't happen. I see three strategies, some of
which have been mentioned already in this thread:
1) Retain the "yyyy.r" part, even though it's year yyyy+1 before the
stable relese is issued.
2008.3.rc5, 2008.3.rc6, [year 2009 arrives], 2008.3.rc7, 2008.3.0
2) Drop the "yyyy.r" and start over with rc1 for "yyyy+1.1".
2008.3.rc5, 2008.3.rc6, [year 2009 arrives], 2009.1.rc1, 2009.1.0
3) Drop the "yyyy.r" in favor of "yyyy+1.1", but don't break the
rc# numbering:
2008.3.rc5, 2008.3.rc6, [year 2009 arrives], 2009.1.rc7, 2009.1.0
The last varient seems strange on the surface, but I think it
would be easier in practice, because developers could refer to "rc5",
"rc6", "rc7", dropping the locally-constant bits will less potential
ambiguity than if the "rc#" sequence was interrupted.
Craig Milo Rogers
On Saturday 2008-07-19 22:56, [email protected] wrote:
> On Sat, 19 Jul 2008, Craig Milo Rogers wrote:
>> On 08.07.19, Rene Herman wrote:
>>
>>> Really, find me a single Linux developer who wouldn't try just a
>>> little bit harder for a big 3.0 release. This is still a
>>> community, not yet a boring office schedule...
>>
>> I'm afraid that the allure of 3.0 would mean that everyone
>> would want to get their shiny new subsystem/scheduler
>> rewrite/bootstrap file format change/whatever incorporated into it
Which is why it should not be announced early, but happen
spontaenously at Linus's discretion, right after the last -rc.
>> it, resulting in a protracted integration period and an unstable
>> system. According to this line of thought, Linus should simply
>> announce version 3.0 with no forewarning...
>
> not to mention that people would avoid it becouse it would be a .0
> release and therefor perceived as being unstable (and for the
> reasons that Craig lists, they would probably be right)
Maybe we should also start skipping on numbers like 2.x.4, 2.x.13,
and 2.6.66.
"What's in a number?"
Maybe we should only ever release 2.<odd>.0 to show that there is
nothing bad about being an <odd> or a .0 release.
Craig Milo Rogers <[email protected]> wrote:
>> rename 2.6.28 to 2.8.0
>> or
>> rename 2.6.29 to 2.9.0
>> or
>> rename 2.6.30 to 3.0.0
>>
>> i.e. .. whatever you are doing now, just drop the first two numbers (the
>> "2.6" bit) since they seem to be constant.
> So you're saying that the formula is to drop the "2.6" and place
> a period between the first and sedond digits of what's currently the
> release number? OK, I hadn't interpreted it that way. Does the sequence
> continue like this?
The point is to rebase to a new system at a point coming up which is
convenient. There is an opportunity at 2.6.28, which can be renamed
2.8.0, dropping the constant 2.6.
I suppose one counts 2.8.1, 2.8.2 from then on, or does whatever else
one wants to do. I don't know - Linus' only objective is to get smaller
more meaningful numbers and the details of how one counts afterwards
don't matter.
Or if one misses the 2.6.28 point, one gets another good opportunity for
rebasing at 2.6.30, which could become 3.0.0, dropping the constant 2.6
again.
>> Remember that Linus' only objective is to have smaller numbers, which
>> may therefore
>>
>> 1) be memorable
>> 2) be good advertising copy
>> 3) be meaningful
>>
>> and that was the only intention of my scheme: "drop the constant bit".
> And the underlying problem is that there are only so many
> small numbers.
We need smaller numbers now.
I.e. We're happy with the system we've got, except for the high
numbers we're at, so just rebase.
Peter
On 19-07-08 22:49, Craig Milo Rogers wrote:
> On 08.07.19, Rene Herman wrote:
>> Really, find me a single Linux developer who wouldn't try just a little bit
>> harder for a big 3.0 release. This is still a community, not yet a boring
>> office schedule...
>
> I'm afraid that the allure of 3.0 would mean that everyone
> would want to get their shiny new subsystem/scheduler
> rewrite/bootstrap file format change/whatever incorporated into it,
> resulting in a protracted integration period and an unstable system.
> According to this line of thought, Linus should simply announce
> version 3.0 with no forewarning...
Or better yet, we'd have 342 -rc's and a REALLY big party when 3.0
finally hits the streets.
See. You guys just don't think "fun"...
Rene.
On Sunday 20 July 2008, Rene Herman wrote:
> On 19-07-08 22:49, Craig Milo Rogers wrote:
> > On 08.07.19, Rene Herman wrote:
> >> Really, find me a single Linux developer who wouldn't try just a little
> >> bit harder for a big 3.0 release. This is still a community, not yet a
> >> boring office schedule...
> >
> > I'm afraid that the allure of 3.0 would mean that everyone
> > would want to get their shiny new subsystem/scheduler
> > rewrite/bootstrap file format change/whatever incorporated into it,
> > resulting in a protracted integration period and an unstable system.
> > According to this line of thought, Linus should simply announce
> > version 3.0 with no forewarning...
>
> Or better yet, we'd have 342 -rc's and a REALLY big party when 3.0
> finally hits the streets.
I suggest that major and minor versions follow some milestones (as suggested
to a message that I cannot reply directly). For example:
Starting from 'today', mark all open bugs and change version to 2.7 when all
those bugs are closed. Then mark the open bugs of that time and change to 2.8
when those bugs are fixed. Repeat as needed.
Set a 'target'/goal and change version to 3.0 whenever worldwide linux
server/desktop percentage reaches XX%. (Of course this may happen before
changing to 2.7 but this is not a bad thing (tm)). Then set another target
(that may not be related to linux adoption) etc, etc...
This will keep the current versioning scheme, set some common goals for all
developers, add more meaning into trying to fix bugs and prevent the world
from experiencing large linux version numbers.
As a side-effect, setting targets like those may make the whole community
cooperate even more/better by having common long-term goals.
...
p.s You could also keep the X.Y.Z notation and change the major version
number whenever the way of versioning changes (and the current one is
actually version 2) :P