[Mesa-dev] Move mesa version scheme to a more common style ?

[Emil Velikov]

On 14/11/14 15:07, Erik Faye-Lund wrote:
> On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> Hello all,
>>
>> This is an old question that I had laying around - why doesn't mesa use
>> a more conventional numbering for the development/rc releases ?
>>
>> Eg.
>> mesa 10.4.0-rc1 -> 10.3.99.901
>> mesa 10.4.0-rc2 -> 10.3.99.902
>> ...
>> mesa 10.4.0     -> 10.4.0
>> mesa 10.4.1-rc1 -> 10.4.0.901
>> ... you get the idea.
>>
>> Afaics most freedesktop project use it plus a big hunk of gnome.
> 
> Does this really make it a more conventional numbering scheme? I've
> personally seen the "10.4.1-rc1"-scheme way more often than the
> "10.4.0.901"-scheme. In fact, I think this is the first time I've seen
> the latter used. But I haven't exactly gone out of my way looking for
> versioning schemes.
> 
Come on Eric, seriously ?

Most/all the projects that I can see on fd.o and gnome, that have stable
branches use this scheme. Eg. libX11, libXext, xorg-server, evince,
clutter... I would love to be proven wrong, that they are the minority.

>> Are there any objections if I move to the above format starting with
>> mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days,
>> and based on it I'll tag the first RC.
> 
> Shouldn't it be the other way around? IMO we should have strong
> arguments for *changing* it, rather than keep going as-is... Any
> change can break something, so only changes that have clear benefits
> should be done, no?
> 
Note that we're talking about the rc versions/development branch. For
releases things are as normal. Most of the times I tend to think hard
before I propose something that seems ground breaking, and in this case
I cannot even remotely see a case where something will break.

This almost sounds like "don't go outside because something can fall
from the sky and hit you". No disrespect there.

I'll take your and Ilia's views, and would encourage the input from
someone that has done this sort of thing (stable branches).

Cheers,
Emil

> AFAICT, the current scheme conveys more relevant, obvious information
> than the proposed one, namely that it's a release *candidate* for
> v10.4.1. If no blocking issues are found, it'll become the *actual*
> release...
>