mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Stoyan Gaydarov <stoyboyker@gmail.com>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	gorcunov@gmail.com, akpm@linux-foundation.org, mingo@elte.hu
Subject: Re: From 2.4 to 2.6 to 2.7?
Date: Mon, 14 Jul 2008 19:47:46 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0807141939410.3017@woody.linux-foundation.org> (raw)
In-Reply-To: <6d291e080807141931g3080c94cic94f503c1a18523b@mail.gmail.com>



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

  reply	other threads:[~2008-07-15  2:48 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-15  2:10 Stoyan Gaydarov
2008-07-15  2:22 ` Linus Torvalds
2008-07-15  2:31   ` Stoyan Gaydarov
2008-07-15  2:47     ` Linus Torvalds [this message]
2008-07-15  3:55       ` david
2008-07-15  5:31         ` Willy Tarreau
2008-07-15  6:40           ` Rafael C. de Almeida
2008-07-15  7:23           ` Stoyan Gaydarov
2008-07-15  7:49       ` Jan Engelhardt
2008-07-17 17:25         ` Jan Engelhardt
2008-07-17 19:56           ` Craig Milo Rogers
2008-07-17 20:21             ` Jan Engelhardt
2008-07-19  8:00               ` Craig Milo Rogers
2008-07-19  8:52                 ` Rene Herman
2008-07-19 20:49                   ` Craig Milo Rogers
2008-07-19 20:56                     ` david
2008-07-19 21:56                       ` Jan Engelhardt
2008-07-20  8:34                     ` Rene Herman
2008-07-20 14:53                       ` Stefanos Harhalakis
2008-07-19 19:30                 ` Peter T. Breuer
2008-07-19 21:16                   ` Craig Milo Rogers
2008-07-19 23:10                     ` Peter T. Breuer
2008-07-15  8:29       ` Bernd Petrovitsch
2008-07-15 12:41       ` Kasper Sandberg
2008-07-15 13:18         ` Alberto Gonzalez
2008-07-15 18:06       ` Charles grey wolf Banas
2008-07-15 20:43       ` Adrian Bunk
2008-07-16  7:53         ` Jan Engelhardt
2008-07-16  7:57           ` Rene Herman
2008-07-17 22:16         ` Adrian Bunk
2008-07-15 10:10   ` Andi Kleen
2008-07-15 11:31     ` Jan Engelhardt
2008-07-15 15:20     ` Linus Torvalds
2008-07-15 15:27     ` Parag Warudkar
2008-07-15 15:32       ` Alan Cox
2008-07-18  9:02         ` Andi Kleen
2008-07-16 21:11     ` Lennart Sorensen
2008-07-15 12:38   ` Alan Cox
2008-07-15 14:07   ` Byron Stanoszek
2008-07-16 21:14     ` Lennart Sorensen
2008-07-17  0:03       ` Alex Chiang
2008-07-17 12:38         ` Lennart Sorensen
2008-07-17 20:02           ` Alex Chiang
2008-07-15 14:24   ` Cyrill Gorcunov
2008-07-15 16:36     ` Tobias Brox
2008-07-15 18:04   ` H. Peter Anvin
2008-07-16  4:22     ` Rene Herman
2008-07-16  6:55       ` Rafael C. de Almeida
2008-07-16  7:17         ` Rene Herman
2008-07-16  7:30         ` Rene Herman
2008-07-16  9:34       ` Peter T. Breuer
2008-07-17 22:05 Alastair Stevens
2008-07-17 22:40 ` Lennart Sorensen
2008-07-18  8:23   ` Peter T. Breuer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.1.10.0807141939410.3017@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gorcunov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stoyboyker@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®