(Short?) merge window reminder

[Tony Luck]

On Wed, May 25, 2011 at 7:12 AM, Boaz Harrosh <bharrosh at 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"!).

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

-Tony