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

[Jonathan Gray]

On Mon, Dec 12, 2016 at 03:28:45PM +0000, Emil Velikov wrote:
> [adding mesa-maintainers to the mix]
> 
> On 1 October 2016 at 20:46, Marek Ol????k <maraeo at gmail.com> 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.
> >
> Afaict the only expectation from version numbers, is to never go back
> in time. Anything else is a manner of personal interpretation and
> there is will always someone who get confused.
> Look at how [some] projects steadily roll in their 50s ;-)
> 
> That said, having a bit of a change is a good idea, esp. since we're
> unlikely to have a major bump anytime soon.
> 
> 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.
> 
>  * Distro/package maintainers, let us know if the above sounds fine on your end.
> 
> Since this will have an impact on the tarball URL I'm bringing forward
> a question which has been asked a few times:
> 
>  * Should we drop the $VERSION directory in the URL, since it causes a
> fair bit of nuisance during RC stage.
> Namely from:
> https://mesa.freedesktop.org/archive/$VERSION/mesa-$VERSION.tar.{xz,gz}
> to:
> https://mesa.freedesktop.org/archive/mesa-$VERSION.tar.{xz,gz}
> 
> Maintainers, kindly reply on both topics, even if you're neutral.

On the OpenBSD side, Mesa is imported into a larger tree (xenocara)
which has libdrm, xorg, fonts etc, so location of the distfile isn't a
problem.  The version would only show up in the form of pkg-config
files and the version strings accessible from GL contexts.