[Mesa-dev] Proposal of date-based Mesa versioning for 2017

[Marek Olšák]

On Mon, Dec 12, 2016 at 6:04 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Mon, Dec 12, 2016 at 8:57 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>
>> On Mon, Dec 12, 2016 at 4:46 PM, Nicolai Hähnle <nhaehnle at gmail.com>
>> wrote:
>> > On 12.12.2016 16:41, Daniel Stone wrote:
>> >>
>> >> On 12 December 2016 at 15:28, Emil Velikov <emil.l.velikov at gmail.com>
>> >> wrote:
>> >>>
>> >>> As mentioned by others - having the second number represent the month
>> >>> would be better, afaict.
>> >>> Namely: YY.MM.PP. Thus 17.02.01 provides direct and clear feedback
>> >>> that
>> >>>  - 2017 release, from the second month (Feb).
>> >>>  - first bugfix release.
>> >>
>> >>
>> >> Not being funny, but does this mean that 17.02 bugfix releases would
>> >> have to all be done in February, or could yyyy.mm.xx with xx > 0, mean
>> >> that the release was not done in that month, but just the branching
>> >> was?
>> >
>> >
>> > While I think the answer to that _should_ be obvious (just look at
>> > Ubuntu
>> > LTS version numbers...), it is one reason why I'm not too keen about
>> > using
>> > the month. I'd say YY.AA.PP with YY = year, AA, PP = simply incrementing
>> > should be good enough and avoids silly questions like do we take the
>> > month
>> > of the release or of the first -rc? What if the release slips into the
>> > next
>> > month by a few days?
>>
>> I second that. YY.AA where YY=year, AA \in {0,1,2,3}.
>
>
> Agreed.  It also reduces confusion about what to expect the next version
> number to be and "where did 17.3 go?  Oh wait, there wasn't one".  Ubuntu is
> consistent enough that they always do .4 and .10 so people know exactly
> what's coming.  We aren't that consistent so I think having it be YY.MM for
> some random set of MM will just confuse people.
>
> Marek, Did you mean YY.AA or YY.A?  I don't think we need two digits for the
> minor number.

YY.A

Marek