Re: RFD: Kernel release numbering

David Lang
2005-03-03T17:54:14Z

On Thu, 3 Mar 2005, Neil Brown wrote:

> On Wednesday March 2, davem@davemloft.net wrote:
>> On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <jgarzik@pobox.com> 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