On Sun, Oct 2, 2016 at 5:04 AM, Kenneth Graunke <kenn...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev