Re: RFD: Kernel release numbering

[David Lang]

On Thu, 3 Mar 2005, Neil Brown wrote:

> On Wednesday March 2, davem@xxxxxxxxxxxxx wrote:
> > On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
> >
> > > If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is
> > > preferable to even/odd.
> >
> > All of these arguments are circular.  If people think that even/odd
> > will devalue odd releases, guess what 2.6.x.y will do?  By that line
> > of reasoning nobody will test 2.6.x just the same as they aren't
> > testing 2.6.x-rc* right now.
>
> I think there is a qualitative difference.
> 2.6.x is the end of a line that 2.6.x-rc* leads up to.  There is a
> clear end.  "I will test when it gets to the end".
>
> 2.6.x.y doesn't.  If the releases are quick (daily if there is
> anything to release) then there is no clear end to the list, just a
> beginning.  There may never be a 2.6.x.1 for some values of x, so
> people won't be able to wait for the .1 or the .2 release.  They will
> have to just take what is available when they want to upgrade.

as one of the users since the mid 2.0 series. I really think this is the 
best approach.

with any 'stable' kernel series I have always had to wait at least a few 
days from the release to allow people to report brown-bag problems, and 
then I've needed to test it on my particular hardware to make sure there 
are no driver gotcha's that happen to bite my configuration, then I can 
deploy (either immediatly if it's a security issue, or after load testing 
if it's not)

the 2.6.odd/even won't change this at all

the 2.6.x.y will leave me needing to do the same thing for each new x, but 
any new .y releases that take place should be able to follow a more rapid 
path as they will probably have _very_ few changes in them (i.e. no driver 
updates that aren't significant bugfixes). and the ability to do more then 
one .y release if nessasary without confusing people is definantly an 
advantage over the odd/even approach

> If we want to stop people from waiting for a final release before they
> test, we need to make sure there isn't a (recognisable in advance)
> final release.

good point

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/