Re: (Short?) merge window reminder

[Boaz Harrosh <bharrosh@panasas.com>]

On 05/26/2011 01:21 AM, Tony Luck wrote:
> On Wed, May 25, 2011 at 7:12 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>> So if you combine all the above:
>>
>> D. Y. N
>> D - Is the decade since birth (1991 not 1990)
>> Y - is the year in the decade so you have 3.1.x, 3.2.x, .. 3.10.x, 4.1.X and so on
>>    Nice incremental number.
>> N - The Linus release of this Year. So this 3rd one goes up to 4 most probably.
>>
>> Linus always likes, and feels very poetic about the Christmas version release.
>> He hates it when once it slipped into the next year. So now he gets to increment
>> the second digit as a bonus.
>>
>> The 2nd digit gets to start on a *one*, never zero and goes up to *10*, to symbolize
>> the 1991 birth. And we never have .zero quality, right?
>>
>> The first Digit gets incremented on decade from 1991 so on 2011 and not 2010
> 
> This is clearly the best suggestion so far - small numbers, somewhat
> date related (but without stuffing a "2011." on the front).  No ".0"
> releases, ever.
> 
> But best of all it defines now when we will switch to 4.x.y and 5.x.y
> so we don't have to keep having this discussion whenever someone thinks
> that the numbers are getting "too big" (well perhaps when we get to the
> tenth decade or so :-)
> 
> So the only thing left to argue is whether the upcoming release should
> be numbered "3.1.1" as the first release in the first year of the 3rd
> decade ...  or whether we should count 2.6.37 .. 2.6.39 as the first
> three releases this year and thus we ought to start with "3.1.4" (so we
> start with "pi"!).
> 

Yes, Yes I like this a lot. I love pi, thanks.

Boaz
> Linus: If you go with this, you should let Boaz set the new "NAME"
> as a prize for such an inspired solution.
> 
> -Tony