login
Search
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
--
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
--
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"
--
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
--
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.
--
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
--
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 keepI 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 theyWell, 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--
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 niceI 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.
--
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.
--
[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 ...
Areas? "Target audience groups" maybe? Well, I'm also not a native
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
--
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
--
Didn't HP-UX 11 come out around a decade ago? Did they stop
development?--
Len Sorensen
--
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
--
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
--
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
--
Or you could just do it like emacs or Solaris and simply use a single number.
-Andi
--
Oh just like 'less'. I currently have version 418 of less installed it
would seem.--
Len Sorensen
--
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
--
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, Jul 14, 2008 at 9:22 PM, Linus Torvalds
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
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
--
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
--
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 releasecu
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--
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--
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
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1It 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.-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.orgiD8DBQFIfOcLi1yS1BuzIvgRAnW9AKCSBqFsctCS58XdZ81QdnSuMB4WpQCfbPTf
qTRm2dSF6OyvyTrN8cR4XzM=
=VcmW
-----END PGP SIGNATURE-----
--
I like the current numbering fine.. my suggestion is to keep the current
model, there are various reasons1: it requires no effort
2: various things doesent break
3: naming isnt _THAT_ importantthen 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--
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...
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.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--
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.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 magnitude2.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.
--
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.--
Use 2.8 in 2008, 2.9 in 2009, 2.10 in 2010, etc?
Craig Milo Rogers
--
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 <alpine.LFD.1.10.0807141914280.3017@woody.linux-foundation.org>,
Linus Torvalds proposed two possible new patterns:yyyy.month
decade.year.releaseIn <alpine.LFD.1.10.0807141939410.3017@woody.linux-foundation.org>,
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 <20080715053101.GJ1369@1wt.eu>, Willy Tarreau proposed:
y.r.s (y = yyyy - 2000), e.g. use 9.r.s in 2009, 10.r.s in 2010In <487C4646.7020905@gmail.com>, 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
<87skubxxtq.fsf@basil.nowhere.org> Andi Kleen proposed using a single
number like Solaris.In <20080715133801.546...
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.0i.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 therefore1) be memorable
2) be good advertising copy
3) be meaningfuland that was the only intention of my scheme: "drop the constant bit".
Peter
--
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?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
--
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.6We 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
--
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.
--
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
--
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.
--
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
--
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
--
Which is why it should not be announced early, but happen
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.
--
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 thing2. 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.2so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
--
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.agreed, but with Y.r.s :-)
Willy
--
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-Stoyan
--
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?
--
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Antonio Almeida | HTB accuracy for high speed |
