 |
mail4liste.de
Mailinglist2forum
|
| Print this topic :: View previous topic :: View next topic |
| Author |
Message |
Stoyan Gaydarov
Guest
|
 Posted: Tue Jul 15, 2008 3:10 am Post subject: From 2.4 to 2.6 to 2.7? |
 |
|
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Linus Torvalds
Guest
|
| Posted: Tue Jul 15, 2008 3:22 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
| Quote: |
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Stoyan Gaydarov
Guest
|
| Posted: Tue Jul 15, 2008 3:31 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, Jul 14, 2008 at 9:22 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
| Quote: |
On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
| Quote: |
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
| Quote: |
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
| Quote: |
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?
| Quote: |
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
| Quote: |
But three-year development trees with a concurrent stable tree? Nope. Not
going to happen.
Linus
|
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Linus Torvalds
Guest
|
| Posted: Tue Jul 15, 2008 3:48 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
| Quote: | | Quote: |
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
david
Guest
|
| Posted: Tue Jul 15, 2008 4:55 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, 14 Jul 2008, Linus Torvalds wrote:
| Quote: | | Quote: | 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
| Quote: | 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Willy Tarreau
Guest
|
| Posted: Tue Jul 15, 2008 6:31 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, Jul 14, 2008 at 08:55:59PM -0700, david@lang.hm wrote:
| Quote: | On Mon, 14 Jul 2008, Linus Torvalds wrote:
| Quote: | | Quote: | 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.
| Quote: | so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
|
agreed, but with Y.r.s :-)
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Rafael C. de Almeida
Guest
|
| Posted: Tue Jul 15, 2008 7:40 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
Willy Tarreau wrote:
| Quote: | On Mon, Jul 14, 2008 at 08:55:59PM -0700, david@lang.hm wrote:
| Quote: | On Mon, 14 Jul 2008, Linus Torvalds wrote:
| Quote: | | Quote: | 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.
| Quote: | | Quote: | so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
|
agreed, but with Y.r.s :-)
Willy
|
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Stoyan Gaydarov
Guest
|
| Posted: Tue Jul 15, 2008 8:24 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Tue, Jul 15, 2008 at 12:31 AM, Willy Tarreau <w@1wt.eu> wrote:
| Quote: | On Mon, Jul 14, 2008 at 08:55:59PM -0700, david@lang.hm wrote:
| Quote: | On Mon, 14 Jul 2008, Linus Torvalds wrote:
| Quote: | | Quote: | 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.
| Quote: | 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
-Stoyan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Jan Engelhardt
Guest
|
| Posted: Tue Jul 15, 2008 8:49 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Tuesday 2008-07-15 04:47, Linus Torvalds wrote:
| Quote: |
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]:
| Quote: | 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.
| Quote: | 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Bernd Petrovitsch
Guest
|
| Posted: Tue Jul 15, 2008 9:33 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, 2008-07-14 at 19:47 -0700, Linus Torvalds wrote:
| Quote: | On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
| Quote: | | Quote: | 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.
[...]
| Quote: | 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Andi Kleen
Guest
|
| Posted: Tue Jul 15, 2008 11:10 am Post subject: From 2.4 to 2.6 to 2.7? |
|
|
Linus Torvalds <torvalds@linux-foundation.org> writes:
| Quote: |
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Jan Engelhardt
Guest
|
| Posted: Tue Jul 15, 2008 12:31 pm Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Tuesday 2008-07-15 12:10, Andi Kleen wrote:
| Quote: | Linus Torvalds <torvalds@linux-foundation.org> writes:
| Quote: |
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Kasper Sandberg
Guest
|
| Posted: Tue Jul 15, 2008 1:48 pm Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, 2008-07-14 at 19:47 -0700, Linus Torvalds wrote:
| Quote: |
On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
|
<snip>
| Quote: | 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Byron Stanoszek
Guest
|
| Posted: Tue Jul 15, 2008 3:20 pm Post subject: From 2.4 to 2.6 to 2.7? |
|
|
On Mon, 14 Jul 2008, Linus Torvalds wrote:
| Quote: | 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
Cyrill Gorcunov
Guest
|
| Posted: Tue Jul 15, 2008 3:25 pm Post subject: From 2.4 to 2.6 to 2.7? |
|
|
[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 -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Impressum | 
Profile 
FAQ 
Search 
Memberlist 
Usergroups 
Log in
Register
