[Mesa-dev] Proposal of date-based Mesa versioning for 2017
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:
>> 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.
> 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.
More information about the mesa-dev