Kernel Release Numbering Redux

Submitted by Jeremy
on July 15, 2008 - 12:14pm

For many years, each Linux kernel release was assigned a series of three numbers, X.Y.Z, with an even Y indicating a "stable" release, and an odd Y indicating an "unstable" development release. Z was incremented for each individual kernel release. The "stable" 1.0.0 Linux kernel was released in March of 1994. New development was then continued in the "unstable" 1.1.z branch, until the "stable" 1.2.0 Linux kernel was release in March of 1995. Major improvements in the kernel lead to X being incremented to 2, and a "stable" 2.0 kernel was released in June of 1996. Active development then continued in the "unstable" 2.1 tree. This process continued with "stable" 2.2, 2.4 and 2.6 kernel trees, and each stable tree gained an official maintainer while Linux creator Linus Torvalds focused on newer features in the next "unstable" tree. Development in these "unstable" trees could go on for periods of multiple years before a "stable" tree was branched.

This long-standing odd/even development model was officially scrapped in 2004 thanks to the success that Linus and Andrew Morton were having working together, and significant "unstable" development began happening between each 2.6.Z release. In a recent thread it was asked what it would take for an "unstable" 2.7 development tree to be created, to which Linus noted replied:

"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. [..] 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'?"

Linus continued:

"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 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.."

Linus also noted that he had been planning to discuss his new numbering idea at the upcoming Linux kernel summit in front of a smaller audience, but as the question was asked he answered it. He added:

"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."

In conclusion, Linus quipped, "let the bike-shed-painting begin."


From: Stoyan Gaydarov
Subject: From 2.4 to 2.6 to 2.7?
Date: Jul 14, 7:10 pm 2008

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
--

From: Linus Torvalds Subject: Re: From 2.4 to 2.6 to 2.7? Date: Jul 14, 7:22 pm 2008 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 --
From: Stoyan Gaydarov Subject: Re: From 2.4 to 2.6 to 2.7? Date: Jul 14, 7:31 pm 2008 On Mon, Jul 14, 2008 at 9:22 PM, Linus Torvalds <torvalds@linux-foundation.org> 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 > --
From: Linus Torvalds Subject: Re: From 2.4 to 2.6 to 2.7? Date: Jul 14, 7:47 pm 2008 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 --
From: Jan Engelhardt Subject: Re: From 2.4 to 2.6 to 2.7? Date: Jul 15, 4:31 am 2008 On Tuesday 2008-07-15 12:10, Andi Kleen wrote: >Linus Torvalds <torvalds@linux-foundation.org> 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. --

From: H. Peter Anvin
Subject: Re: From 2.4 to 2.6 to 2.7?
Date: Jul 15, 11:04 am 2008

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
--

From: Andi Kleen Subject: Re: From 2.4 to 2.6 to 2.7? Date: Jul 15, 3:10 am 2008 Linus Torvalds <torvalds@linux-foundation.org> 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 --
From: Linus Torvalds Subject: Re: From 2.4 to 2.6 to 2.7? Date: Jul 15, 8:20 am 2008 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 --

From: Byron Stanoszek
Subject: Re: From 2.4 to 2.6 to 2.7?
Date: Jul 15, 7:07 am 2008

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

--

From: Charles grey wolf Banas
Subject: Re: From 2.4 to 2.6 to 2.7?
Date: Jul 15, 11:06 am 2008

-----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 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/
> 

-----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-----
--

From: Kasper Sandberg
Subject: Re: From 2.4 to 2.6 to 2.7?
Date: Jul 15, 5:41 am 2008

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

--

From: Jan Engelhardt
Subject: Re: From 2.4 to 2.6 to 2.7?
Date: Jul 15, 12:49 am 2008

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.
--

From: david
Subject: Re: From 2.4 to 2.6 to 2.7?
Date: Jul 14, 8:55 pm 2008

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 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/
>
--

From: Willy Tarreau Subject: Re: From 2.4 to 2.6 to 2.7? Date: Jul 14, 10:31 pm 2008 On Mon, Jul 14, 2008 at 08:55:59PM -0700, david@lang.hm 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 --

No return to stable/unstable era

Anonymous (not verified)
on
July 15, 2008 - 2:30pm

Glad to hear this from Lignus. I am amazed people look fondly back on the stable/unstable branch era. It sucked. The current situation is vastly superior. That said, a Solaris-like renumbering scheme for incremental releases might be better marketing. Linux releases are major accomplishments. They shouldn't be obscured by incrementing a third minor number.

We could switch to a mix of

sysuser (not verified)
on
July 20, 2008 - 5:11am

We could switch to a mix of numbers and letters, such as a N.N[A] (number.number[letter]) scheme.
- First number would be increased only for real major rewrites (great infrastructuremodifications/incompatible API changes: 2.7 > 3.0 > 4.0 ... > 10.0)
- second number for new addition (e.g. new driver: 2.7 > 2.8 > 2.9 ... 2.99)
- letter would be used _only_ for bugfix patches (2.7 > 2.7a > 2.7b ... 2.7z).

So one sysadmin could decide beforehand if he is interested to an upgrade or not (not all distributions backport bug fixes to previous kernels ...).

> Let the bike-shed-painting

Anonymous (not verified)
on
July 15, 2008 - 5:23pm

> Let the bike-shed-painting begin.

May I propose Roman numbering?
Apple does it so it must be cool ;)

Now it's official

Jack Ripoff (not verified)
on
July 15, 2008 - 5:41pm

I'm migrating all my remaining Linux servers to BSD...

Seriously? Because some

Anonymous (not verified)
on
July 15, 2008 - 7:22pm

Seriously? Because some people are talking about adopting a more sane version numbering scheme? I sure hope you aren't providing support for someone's business or anything important like that.

Huh?

Jack Ripoff (not verified)
on
July 15, 2008 - 8:38pm

"Seriously? Because some people are talking about adopting a more sane version numbering scheme?"

I'm talking about the new development model.

Since now it's permanent and it doesn't produce stable software, I'd rather run a more guaranteed OS on my servers.

"I sure hope you aren't providing support for someone's business or anything important like that."

You damn troll, why have I even bothered replying to you?

In what way is the linux

Anonymous (not verified)
on
July 15, 2008 - 11:33pm

In what way is the linux development model different from OpenBSD's development model?

In this way

Jack Ripoff (not verified)
on
July 16, 2008 - 8:44am

I think this illustrates the difference better than anything else:

Linux - http://kerneltrap.org/mailarchive/linux-kernel/2008/7/15/2497674
OpenBSD - http://www.openbsd.org/security.html

That's your reason?

Peder (not verified)
on
July 16, 2008 - 6:15am

I'm talking about the new development model.
Since now it's permanent ...

Ehh, FYI this new development model has been around pretty much since 2004 (http://kerneltrap.org/node/5040)
Have you been waiting for a "stable" kernel since then?? (Not to mention that 2.6.0 per the old definition was a stable kernel, based on the unstable 2.5 version)

Feel free to move to the BSD camp, they produce great OS:es as well, but if you want to announce it like this you need to come up with a much better reason.

Yes, it is.

Jack Ripoff (not verified)
on
July 16, 2008 - 8:41am

"Have you been waiting for a "stable" kernel since then??"

Yes, I was hoping a 2.7.x branch would eventually come up and the 2.6.x branch would then begin to freeze. I didn't want to go through the hassle of migrating the servers to a different OS without being sure this new development model is permanent.

"Feel free to move to the BSD camp, they produce great OS:es as well, but if you want to announce it like this you need to come up with a much better reason."

The reason is: the Linux kernel is now officially unstable.

The reason is: the Linux

Jeff (not verified)
on
July 16, 2008 - 9:42am

The reason is: the Linux kernel is now officially unstable.

Life is unstable. Get used to it

Perception and reality

on
July 16, 2008 - 10:05am

Ok, so you've waited 4 years. Are you making your decisions based on actual utility and actual measurement, or based on perception and wishful thinking? 4 years is a long time to tread water. If any instability you experienced was material, wouldn't it have been such an issue you would have switched by now?

And besides, are you running a Linus kernel or a vendor kernel? Linus' is the development branch. The big mental shift in the development methodology was to eliminate the schizophrenia and not make the development branch do double duty as the release branch for extended periods of time. Distros now own the release branches.

--
Program Intellivision and play Space Patrol!

"Ok, so you've waited 4

Jack Ripoff (not verified)
on
July 16, 2008 - 3:42pm

"Ok, so you've waited 4 years. Are you making your decisions based on actual utility and actual measurement, or based on perception and wishful thinking? 4 years is a long time to tread water. If any instability you experienced was material, wouldn't it have been such an issue you would have switched by now?"

I don't want to be rude, but what part of "I'd rather run a more guaranteed OS on my servers" didn't you get? I just want a guarantee - and so do my clients.
(I think this qualifies my motives as "anecdotal evidence", but whatever)

"And besides, are you running a Linus kernel or a vendor kernel? Linus' is the development branch. The big mental shift in the development methodology was to eliminate the schizophrenia and not make the development branch do double duty as the release branch for extended periods of time. Distros now own the release branches."

I think the fact that despite the 2.6.16 kernel being established as the the stable kernel for some years (officially by the kernel developers) RHEL 5 shipped with 2.6.18 and so did Debian tells us alot about this...

2.6.16 not officially "stable"

Peder (not verified)
on
July 16, 2008 - 5:34pm

...despite the 2.6.16 kernel being established as the the stable kernel for some years (officially by the kernel developers)

It was never officially established as anything.

One user that had contributed to the kernel decided to backport fixes from the Linus kernel to 2.6.16, using the same guidelines as the "stable" team (http://kerneltrap.org/node/6930).
And since the kernel is GPL and you can do pretty much whatever you want with it (withing the GPL limits) the "stable" team said "Fine, good luck to you!".

Exactly the same as the distros are backporting fixes to "their" stable kernels.

Before jumping ship, please try the Ubuntu LTS sever for instance. It's stable/frozen/whatever until 2013 so you won't have any new features, only backported fixes, until then.
Good enough for ya' ??

Fine

Jack Ripoff (not verified)
on
July 16, 2008 - 8:57pm

"It was never officially established as anything.

One user that had contributed to the kernel decided to backport fixes from the Linus kernel to 2.6.16, using the same guidelines as the 'stable' team (http://kerneltrap.org/node/6930).
And since the kernel is GPL and you can do pretty much whatever you want with it (withing the GPL limits) the 'stable' team said 'Fine, good luck to you!'."

So, how exactly does that affect my point?

"Before jumping ship, please try the Ubuntu LTS sever for instance. It's stable/frozen/whatever until 2013 so you won't have any new features, only backported fixes, until then.
Good enough for ya' ??"

That's not exactly the point but, whatever, I might try it, thank you.

Windows Enterprise?

Peder (not verified)
on
July 16, 2008 - 5:43pm

I'd rather run a more guaranteed OS on my servers

Hmmm, if you want a guaranteed OS (whatever that means) I'd stay away from the BSD camp as well.
They have roughly the same bugs as linux has (with probably slightly worse fixing times, though that's just a guess on my part).

Microsoft has a Windows version (Enterprise) where they decide the hardware and won't even let you patch the OS yourself. Perhaps that's guaranteed enough?

What do you mean, non-free software?

Jack Ripoff (not verified)
on
July 16, 2008 - 8:44pm

I want something libre, mind you.

Nope, it's stable per definition

Peder (not verified)
on
July 16, 2008 - 10:59am

The reason is: the Linux kernel is now officially unstable.

On the contrary actually; it's now (since the kernel summit 2004) officially stable, if you want to play semantics (since there are no "unstable" 2..x releases).

Let's face it: 2.4 had its share of new features and complete rewrites (like the VM ripout in 2.4.10) as well as critical bugs that needed fixing. The notion of an unstable 2.5 was mostly to discourage people from running the early releases on production environments, since the they could be in more or less unbootable/unrunnable state due to the heavy merging.

What has changed in the workflow is that earlier, when the unstable kernel opened, it was like taking the lid off a preassure boiler: you filled the room with so much steam you couldn't see a thing and everyone was running around blind, bumping into each other. Then eventually after 20-30 releases the steam started disappearing and you started to be able to make out some shapes at least.

In the new model you continually open the lid just a bit during the beginning of every release cycle. Yes the room gets a little foggy initially but after a couple of -rc releases everything's in clear view again.

And hey, if you care so much about "stable" there's always the 2.4.36.6 (released on June 6) to use.
It's guaranteed "stable" (not to be mistaken for bug-free though).

But, as I said, if the BSD camp makes you feel cozier, please use their products. Or use Debian-stable; I hear it's ancient but stable so I guess that goes for their kernel as well.

From fast development to

Anonymous (not verified)
on
July 16, 2008 - 1:26am

From fast development to non-development. Oh well, have fun.

Not implied

Anonymous (not verified)
on
July 16, 2008 - 5:28pm

I assumed he was migrating toward FreeBSD. FYI- 7.0 currently outperforms Linux 2.6 by a large margin.

Slower green arrow?

Peder (not verified)
on
July 16, 2008 - 6:03pm

FYI- 7.0 currently outperforms Linux 2.6 by a large margin

And the unbiased testing that backs up your statement is where??

Ok, I don't have any problems with some other kernel being faster than the linux kernel (especially if it's an open/free one), but it has to be backed up by facts. And unless you have all the facts on your sid you can't catigorically claim that X kernel is faster that linux.

Yes, it may be faster in serving http for instance, but what if I just want a NFS server w/o any http access? Or a render farm? Or a server that display a green arrow in the metro (http://www.networkworld.com/community/node/29644?ts).

Can you honestly say that the FreeBSD kernel would display that green arrow faster than a linux kernel...?

And unless you have all the facts on your sid..

JDR (not verified)
on
July 18, 2008 - 5:27am

Hah, that's a fun typo considering sid == unstable in debian land. :-)

Enterprise distros solve the problem

Anonymous (not verified)
on
July 16, 2008 - 1:45pm

Red Hat Enterprise Linux and other distros do stabilize and maintain the OS for many years at a time. More so that what *BSD is doing.

The difference here is that the development kernel is moving fast. The distros kan choose their own speed.

Red Hat Enterprise Linux 3 is still using the version 2.4.x of the Linux kernel. Red Hat do maintain that kernel today.

Stay with 2.x unless something changes

gh (not verified)
on
July 15, 2008 - 7:17pm

I don't see anything wrong with the current scheme. Maybe when we get to 2.6.99 I'll feel differently, but that's at least a few years out. Let's keep it at 2.x until something significant changes. A significant change like a license change would definitely be worthy of a 3.0 version number (GPL v3 anyone?).

For 2.7, there are so many cool features that it is hard to decide which ones are worthy of bumping the middle number -- even harder to predict in advance. It is a marketing game at this point, so which feature(s) do we want to emphasize? Maybe a finished ext4, or BKL (as previously suggested). Perhaps dropping some obsolete features and no-longer-supported hardware (are there any? hehe).

I see a high minor version as a sign of stability, so there's no rush to reset it. It's awesome that we can keep adding features without unstable releases.

gh

If time based versioning, then use true years...

Blc (not verified)
on
July 16, 2008 - 1:59am

...the first release of 2009 be 2.9.1 ... And then 2010 would be 3.0.1 etc..

IMO it's better to use 2009.x and 2010.x and 2011.x ... 2500.x... and so on. Much better than some cryptic 2.9.1 and 3.0.1, 3.1.1 with sudden "new major number" every ten years...

I agree

Bas Hekking (not verified)
on
July 16, 2008 - 5:59pm

I would like YY.M or YYYY.m
I think the date is an important clue and easy to remember

Why not simpler?

Shu (not verified)
on
July 16, 2008 - 2:19am

Why not simply 8.r.s in 2008, 9.r.s in 2009, 10.r.s in 2010, etc.?

It would be OK till 2999, when we will have 999.r.s
In 3000 we can go for 3000.r.s. We have nearly one thousand years to think about it.

r would be release, s the subrelease. Or even r=month, s=day, if you like it more.

I think 2008 is too long. Let's take advantage from the millennium change. :)

Bye.

That's also good but...

Blc (not verified)
on
July 16, 2008 - 3:49am

Why not simply 8.r.s. ? Because 2008 is much more self-explaining at first glance. And I don't think it's that long. :-))

While generally liking the

Anonymous (not verified)
on
July 16, 2008 - 3:33am

While generally liking the new development model, I see one major problem with it. Which is sustained support for a version you have installed.

Specifically, after trying to keep up to date with the latest kernel for some time, I feel I don't really want to upgrade all my machines every couple of months for features or new drivers I don't have a need for. On the other hand, if I stick with say 2.6.24 I can be pretty sure support for it will end once 2.6.25 is out.

So in case any lingering bug pops up later on, ppl will tell me to upgrade to latest instead of providing a targeted fix for my version. Upgrading to latest would introduce lots of other changes though I might not care and not even be enthusiastic about, or which even might introduce some regression in spite of all the testing. Also, out of tree drivers I rely upon may not work anymore with latest.

In other words, with the current model the "maturing" time of each release is just cut short, and long time support effectively rolled over to distro maintainers. Who would also have to provide single handedly backporting of new features which *are* desirable to have.

So even if some ppl might argue that my concerns are mostly psychologically rooted comfort issues, I still think it just makes a difference if a release get's attention from various parties over a sustained period of time. Other than that, it's rather reassuring to see how efficient and steady paced kernel development seems to be these days.

Kernel upgrades?

Anonymous (not verified)
on
July 16, 2008 - 6:42am

I feel I don't really want to upgrade all my machines every couple of months for features or new drivers I don't have a need for.

Why don't you stay with the kernel your distro provides and let them supply you with bug fixes? Every major distro backports bug- and security fixes from the latest kernel to their shipped kernel.

If you're using out of tree drivers why not push the developers to try to get them in-tree (assuming GLP, if you're using closed source ones you're on your own).

Developers cant keep up with the frequency of kernel releases

Anonymous (not verified)
on
July 16, 2008 - 8:04am

The main problem I have right now is the sheer frequency of new kernel releases. A new release comes out every 90 days or so and contains a ton of new functionality, renamed functions, reworked innards, etc. It is a nightmare trying to keep my product's kernel modules working seamlessly across all revisions (i.e. - things I am interested in like memory management, process management, etc are constantly changing).

If Linux wants to get serious about becoming the standard platform for enterprise services, then it is going to have to get back to "stable" or "platform" releases that only come out once or twice a year. Either that, or just designate certain iterations (2.6.9, 2.6.18, 2.6.23, etc) as the platform release around which developers like me can focus our compatibility and testing efforts.

If your modules were

Anonymous (not verified)
on
July 16, 2008 - 8:13am

If your modules were in-tree, then they would be updated for you.

If they're not in tree, the kernel devs' stance is clear - you're on your own.

So if you want help keeping up with internal changes, submit your stuff patch series for review. If you're doing some closed source modules, they explicitly discourage that, so don't expect any accommodations :)

Also, most of the sweeping changes (theoretically) ought to be done by -rc1, and be in the -next tree even before that - so you have plenty of time to prepare for the next release.

So get your kernel module

Anonymous (not verified)
on
July 16, 2008 - 8:25am

So get your kernel module included in the kernel so you don't have to maintain it externally. This is the benefit of the Linux development model. If you can't, or won't adapt to this model then you just have to deal with the issues yourself. Alternatively as mentioned above, you can use an enterprise distribution that minimizes the number of kernel updates dramatically.

Vendor kernels

Anonymous (not verified)
on
July 16, 2008 - 8:54am

This is a typical criticism, unfortunately... After all these years, people still don't understand that the Linus tree isn't meant for production. The Linus tree is a reference for *vendors*. Users should be using the vendor's tree. If they aren't, then they assume the same kind of work vendors have to do to suport their kernel releases. It's that simple.

Sure the Linus' tree is

Anonymous (not verified)
on
July 16, 2008 - 11:36am

Sure the Linus' tree is meant for production. It just isn't meant for the fuddy duddies in the enterprise that want just their bugs fixed.

If you want something that makes it easier on you and harder on the developers to support then you want an enterprise kernel. Where you pay the developers to make your life easier.

I second that version should

Anonymous (not verified)
on
July 16, 2008 - 8:34am

I second that version should have changed when release cycle was changed.

I also agree with Linus that it make no sense to change version numbering for pure sake of changing it.

Though it is really hard to resist against X.Y versioning other systems are using. OpenBSD example stroke me with its simplicity. Unfortunately, it is really hard (impossible) to cram all versions Linux can have into two digits.

I also do no like Y.R.S versioning (Y == year, R == release, S == stable) for simple reasons that Y would leap to be two digit (in 2010). Trying to tie date into (major!) version always seems to me bad idea.

The only sane solution at moment seems to leave it as it is.

My vote's for year.release.stable or similar

on
July 16, 2008 - 10:10am

I'll throw my vote in for a date derived scheme. The year.release.stable type scheme, where y is the last 1-2 digits of the year works ok for me.

Also, the decade.year.release.stable scheme works as well, esp. if you start with this being decade 2, year 8. That actually provides very good continuity with the current version numbers. That's probably its most attractive feature.

--
Program Intellivision and play Space Patrol!

The problem with year.x.y...

David VomLehn (not verified)
on
July 16, 2008 - 4:18pm

The problem with a year.x.y versioning scheme is that you might be near the end of the target year and wind up releasing the next year. For example, say it's December of 2008. You are at 2008.2-rc6. You just aren't able to get all the bugs resolved until January of 2009. So, your release number jumps to 2009.1-rc7, or something like that. It's not going to be very obvious that the next release after 2008.2-rc6 is 2009.1-rc7. You could, of course, make it 2008.2-rc7, but when that comes out in 2009 you get confusion from the difference in years. I think there is a reason that Microsoft is backing away from naming Windows releases after the year; some may claim they're evil, perhaps, but they are definitely not dumb.

Solution

Florian (not verified)
on
July 17, 2008 - 5:00am

So an easy solution for this problem :
2008.0 : first stable release of the year
2008.0++RC1 : first RC of the next release (that will end with a 2008.1 or 2009.0 stable release)
2008.0++RC2 : the second RC
2008.1 : the stable release.

I don't think it's a problem

on
July 18, 2008 - 1:00pm

That's easily solved. Make it the last release of the previous year if an RC has already gone out, or the first release of the next year if the first RC goes out the next year. Whatever year the RC1 goes out in sets it. Or, even easier, just set it based on the year the merge window opens. And to be clear, only the year should be in the version number. It exists only to periodically reset the "release number." Since you only have a handful of releases per year, it keeps the second digit small.

You see something similar with tropical storms / hurricanes, since the season straddles Dec/Jan, but names start over with 'a' in the new year. Which year the storm is considered in is the year in which it crossed the threshold to get a name.

--
Program Intellivision and play Space Patrol!

Save the first number!

Anonymous (not verified)
on
July 17, 2008 - 1:10am

Save the first number! You will need it some day when you decide to do a really big change! (Like a license change to GPLv3 or... a totally different kernel architecture - like a change of programming language etc.)

Is it really impossible to start raising the second number every time there have been bigger changes??? I bet there are releases which have bigger changes than normally, if you look at it from the _user's_ perspective. A change is big if some big part of the kernel is replaced with a new solution or when a new feature is introduced in a way it will affect everyone (not a new feature which can be chosen in/out). I would move from 2.6 to 2.8 then because the 2.x tree uses even/odd scheme (even though it's not exploited any more). When 3.0 is out, you could move to 3.1 next etc.

If it's totally impossible to raise the second number based on the changes (is it - _really_?), I would still keep the first number because _there will_ be a day when you change something drastically. It can take ten or even thirty years, but that day will come. If you really need to put date to the version number, I would do it like this: 2.8 (=2008), 2.9 (=2009), 2.10 (=2010), 2.100 (=2100), 3.0 (=3000) :).

Why not start using the old scheme again but differently?!

Anonymous (not verified)
on
July 17, 2008 - 1:59am

Why don't you just start using the second digit for the thing you are using the third one at the moment?!

I think the problem isn't with 26 being a big number but with having so many dots in the version number.

Why not starting to use even/odd scheme again, but for another purpose! Why not use odd numbers for pre-releases! 2.7.0 would be the first pre-release of 2.8, 2.7.1 would be the second etc. As the third digit grows, the pre-release matures and eventually 2.8 gets out. 2.8.1 would be a bug fix release of 2.8.

So the next time a new kernel is announced, it would be "Linux 2.8", not "Linux 2.6.27". Of course the second digit grows fast, but it doesn't really matter because there would be only two numbers to remember: the major (2) and the release (8, 10, 12, ..., 46).

Using odd numbers for pre-releases would help packagers because then the version numbers would be comparable.

Better...

Anonymous (not verified)
on
July 17, 2008 - 2:26am

It's not good to suddenly start making a lot of new 2.x releases. That also breaks the 2.x tree's versioning logic.

So what should be done is simple: Release 3.0 and then continue releasing 3.release.bugfix

I think that is the simplest and the best solution. That will remove one of the dots, no issues with dates (year change in the middle of a cycle), comparable version numbers, still version numbers which tell something to the user (4.0 would happen when there is something BIG)...

When to release 3.0? That is the question. But I bet there will be a release big enough for that. It doesn't have to be a revolutionary change this time because the versioning scheme change justifies the raise of the first digit. E.g. stable ext4 could be one reason for 3.0.

2.6.27 -> 2.7

Anonymous (not verified)
on
July 17, 2008 - 10:02am

Just take the opportunity of the next upcoming release (2.6.27) to drop the 2.6 prefix, which has been frozen for almost 5 years now (2.6.0 was Dec. 2003).

Then borrow some sanity from the Python release scheme, and go 2.7, 2.8, 2.9, 3.0, ... (If needed to satisfy requirements, break some stuff on purpose for 3.0 ;-)

Doing x.y.27 == 2.7 _now_ would be mnemonic. If versions keep going x.y.27, x.y.28, there will be some chance of confusion later if 2.7, 2.8 are ever used ...

Insanity

Anonymous (not verified)
on
July 18, 2008 - 1:56am

doing 2.7, 2.8, 2.9, 3.0, ... is not sanity but insanity.
If you want increasing numbers, do numbers, and do not
confuse people by adding a dot in between.

The dot pleases Linus: "'big

Anonymous (not verified)
on
July 18, 2008 - 5:40am

The dot pleases Linus: "'big meaningless numbers' are bad. '26' is already pretty big".

He has a point, although big numbers (in roman numerals, to boot) seem to work OK for the NFL's Super Bowl releases ;-)

Memory lane dept.: Twenty years ago, AT&T was paying for magazine ads showing "UNIX SysV" carved in stone.

Roman numerals obscure things

on
July 18, 2008 - 1:03pm

Roman numerals obscure the actual number. I'm pretty sure that's why filmmakers used to put their copyright date in Roman numerals--so that people wouldn't focus on when something was made so much. If it's a timeless work, the fact it was make 37 years ago is something that matters only to the copyright office.

That's exactly the OPPOSITE of what we're trying to achieve.

--
Program Intellivision and play Space Patrol!

LinuXXVII would have a

Anonymous (not verified)
on
July 19, 2008 - 3:36am

LinuXXVII would have a certain ... hmm ... *distinctive* ring to it ...

And it could be kept up for another 22 releases, say 5 or 6 more years, until LinuXLIX.

Then it would be time to repaint the bike shed.

decade.year.number -- the smartest i've heard ever on this subje

Anonymous (not verified)
on
August 14, 2008 - 10:57pm

The scheme .. is the best
for the following reasons:

No need to think what is "worthy" to decide for major
number -- developers can concentrate solely on creating
features, without pressure on this issue.

There is hardly 10 releases per year -- in file listings
kernel archives are always sorted in release order.

Linux was started 1991 - so first number really tells the
count of decades linux has existed (starting from 1 -- not
nerdy, that is).

It is fast to count how long some particular release
has been around -- how many knows when 2.6.10 was released ?

How about doing something useful with version numbers?

yman (not verified)
on
August 20, 2008 - 11:41pm

I really like the KDE release numbering scheme. I think it would be great if a product has a label that says "Compatible with Linux 2.7 or later" or something like that, and then I know it will also work on Linux 2.86 as well, but that it won't work on Linux 2.6.

It's not like I understand anything about kernels, but it would be great if the new release numbering scheme also took such practical considerations into account so that the number would actually be useful, and not just sit there looking pretty.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.