lkml.org 
[lkml]   [2008]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: From 2.4 to 2.6 to 2.7?
Craig Milo Rogers <rogers@isi.edu> wrote:
>> 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.0
>>
>> i.e. .. whatever you are doing now, just drop the first two numbers (the
>> "2.6" bit) since they seem to be constant.

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

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

>> Remember that Linus' only objective is to have smaller numbers, which
>> may therefore
>>
>> 1) be memorable
>> 2) be good advertising copy
>> 3) be meaningful
>>
>> and that was the only intention of my scheme: "drop the constant bit".

> And the underlying problem is that there are only so many
> small numbers.

We 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


\
 
 \ /
  Last update: 2008-07-20 01:13    [W:0.057 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site