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

Marek Olšák maraeo at gmail.com
Sun Oct 2 12:32:39 UTC 2016


On Sun, Oct 2, 2016 at 5:04 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On Saturday, October 1, 2016 9:46:45 PM PDT Marek Olšák wrote:
>> Hi,
>>
>> I propose that we use versioning in the form of "year.quarter".
>>
>> 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
>> quarters of the year, respectively.
>> 2018 would start with 18.0, then 18.1, 18.2, 18.3.
>>
>> The motivation is that you can easily tell when a specific Mesa
>> version was released with an accuracy of 3 months.
>>
>> That's the only scheme that seems practical to me. Everything else
>> seems arbitrary or random.
>>
>> Opinions?
>>
>> Marek
>
> I like it.  We clearly need some kind of new scheme, and date based
> versions are one of the more sensible ones out there.  They fit pretty
> well with our time-based releases.  They make it easy to tell how old
> people's drivers are.  They also avoid the version inflation of "every
> release is a new major version".
>
> One thing that's nice about using quarters is that the versions remain
> sequential (17.0 -> 17.1 -> 17.2 -> ...) while the usual "month of the
> release" scheme isn't (17.2 -> 17.5 -> ???).  Avoids the "but where's
> 17.3???" questions.  Also means the versions are unaffected by any
> schedule slips.
>
> Another way of thinking about it: the first release of the year gets
> a major version bump.  Otherwise, the minor version increments each
> release.  (Equivalent, but works if we change from quarterly releases
> to something more or less frequent.)

Yeah, that's the idea. If there are only 3 releases per year, the last
one should be x.2 regardless of the quarter, However, if we stick to 4
releases per year, the quarters and minor versions will match.

Marek


More information about the mesa-dev mailing list