Mesa May Move To A Date-Based Versioning System

[plonoma]

The need for a new versioning scheme for Mesa is needed since it's nearly at OpenGL 4.5 compliance and we might not see a new OpenGL version for a long time. Under Mesa's current practices with their MAJOR.MINOR versioning system, the major version number is bumped when reaching a new OpenGL support level otherwise the minor version number continues to be bumped until hitting a new OpenGL milestone.

Such shoddy reasoning.
Seriously because the major version wouldn't go up any more is your big problem?
If that's important you could let the major version go up after Nth releases or after a specified-length time period if that's your problem.
Expanding upping major version if one or multiple driver(s) reaches a new OpenGL desktop/ES version in addition to core Mesa would also be a very, very good idea.
Makes Mesa a bit more about the drivers, rather than core mesa.
Drivers are after all the whole point of Mesa.
No reason nor cause for switching to a date-based versioning scheme really.

Sometimes there are delays in the release, such as the recent month long delay.
Date-based versioning could create false expectations of releases being timely.

With the focus beginning to shift to Vulkan, the Mesa version could be tied to that, but instead developers are opting for a date-based approach.

First you say lack of new OpenGL versions is a problem and now you tell me Mesa includes Vulkan?
(And if we extrapolate a bit; future graphics API successors would be included as well.)
Including other graphics API's really goes against your reason given in previous sentences for switching to date-based version numbers.
(Running out of OpenGL versions.)

I hope the developers not only do a Mesa 13 release but also a Mesa 14 release.
Sounds a bit early to switch to date-based version numbering before at least Mesa 14 (corresponding to OpenGL 4.5).
Mesa still got 4.5 and ES 3.2 to finish for most drivers.

I find the reason given for switching to date-based version numbers not good enough, the reasoning behind it is fallacious.
Please don't switch to date-based version numbers.

[schmidtbag]

I think most software should use a date-based versioning system. Particularly, software that will perpetually update and may never break compatibility with any plugins or whatever.

[c117152]

Please stop reinventing the date format and just follow ISO 8601 as in 2016-10-03. It doesn't matter how special you think your use-case.

Here, if I'm looking at ftp listings, I don't want to see mesa-17.1.12 followed by mesa-17.11.12 followed by mesa-17.2.12.

Signed,
Common sense.

[Electric-Gecko]

Personally, I don't like this idea. I think it's better as it is, where the first digit changes whenever the program changes radically. What if a new update is just a minor improvement from last year? You then wouldn't want to make it clear that it's "not a very significant release".
It's good as it is. Just keep it.

I think it makes sense for distro's, as most of what changes is just to reflect changes in other software. However, I don't see why they reapply that "point" format to represent the time of release. Why don't they just call it Ubuntu November 09, or whatever month/year format you prefer?

[Anvil]

does anyone really Care? i guess Kiddies Cared when it came to the Kernel but Linus licked there Ass , numbering it like this is just plain stupid IMO

[c117152]

does anyone really Care? i guess Kiddies Cared when it came to the Kernel but Linus licked there Ass , numbering it like this is just plain stupid IMO

We have a problem when there's a known vulnerability in fubar-17.3.9 and a user ends up "upgrading" to fubar-17.4.1 not knowing about fubar-17.3.10 or that fubar-17.4.1 is the unstable branch that isn't isn't backwards compatible.

And programmers aren't immune. Webkitgtk's brain-dead versioning scheme and insane API deprecation policy combined with their 9hr compile time left out many projects vulnerable. Including non other then emacs.

[trek]

We have a problem when there's a known vulnerability in fubar-17.3.9 and a user ends up "upgrading" to fubar-17.4.1 not knowing about fubar-17.3.10 or that fubar-17.4.1 is the unstable branch that isn't isn't backwards compatible.

don't worry, this isn't gnome

[ElectricPrism]

Can we just do both? Mesa 14.3/16-10

[DanL]

see? here is someone complaining about Firefox versioning!

Only because you goaded them into it. That doesn't count.

Can we just do both? Mesa 14.3/16-10

Please, No! AMD had that with Catalyst and it caused unneeded confusion.

[starshipeleven]

Only because you goaded them into it. That doesn't count.

awwwwwwwwwww.