Developers' Planned Changes Still Coming To Mesa 13.1 / Mesa 17.0

[phoronix]

Phoronix: Developers' Planned Changes Still Coming To Mesa 13.1 / Mesa 17.0

Earlier this week I wrote about a release schedule coming out for Mesa 13.1 that culminates with this next big Mesa update being out in February. Some Mesa developers have now shared the work they still hope to see in this next release...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-Hopes-Still-For-17.0-13.1

[Holograph]

I'm super disappointed to see the stupid date-based versioning idea go forward. I want versions based around the actual progress of the library. A date-based versioning scheme does help people know when a particular version is released, but that isn't something that many people need to know! Why!? Why are they wasting time even considering this? These developers seem to have a major case of ADHD and are getting distracted from their task of programming Mesa, which does not require this switch.

Nobody is going to know if it is worth upgrading to a given version - or even if a given version has improvements for them - or even if a given version is safe for them to try as far as stability goes.

[nomadewolf]

I'm super disappointed to see the stupid date-based versioning idea go forward. I want versions based around the actual progress of the library. A date-based versioning scheme does help people know when a particular version is released, but that isn't something that many people need to know! Why!? Why are they wasting time even considering this? These developers seem to have a major case of ADHD and are getting distracted from their task of programming Mesa, which does not require this switch.

Nobody is going to know if it is worth upgrading to a given version - or even if a given version has improvements for them - or even if a given version is safe for them to try as far as stability goes.

I don't really care either way.
I just want to see the features working without bugs.
For all i care they can start over version 1.0 and stay there forever, if it makes them happy.

[pal666]

Nobody is going to know if it is worth upgrading to a given version - or even if a given version has improvements for them - or even if a given version is safe for them to try as far as stability goes.

this is no different from previous versioning scheme, except stability was always the same (use x.y.1+)

[geearf]

Nobody is going to know if it is worth upgrading to a given version - or even if a given version has improvements for them - or even if a given version is safe for them to try as far as stability goes.

Do you know any of this with current versioning scheme without looking at changelogs or summary?

[Holograph]

Do you know any of this with current versioning scheme without looking at changelogs or summary?

Not 100%, but I know that the difference from 13.0.0 -> 13.0.1 is minor and the difference from 13.0.1 to 13.1 is a bit greater and that if they went to 14.0 (not as a date-based thing), that would be even more significant. Usually, anyway. Definitely more useful than me trying to figure out how much work they might have done in a given timeframe when looking at a date-based version.

That said, I did word my previous reply too strongly. I dislike the idea, but I did make it sound like it's more of an issue than it actually is.

[FLHerne]

There's no plan to drop the bugfix versioning - 17.1.1 will be a bugfix update from 17.1.0 as with almost all projects.

The difference between 13.0->13.1 and 13.1->14 is nonexistent with the system to date - it means that some driver (most likely not one you're using) supports a newer OpenGL version. GL versions are fairly arbitrary collections of extensions, so the only information in either case is that at least one driver added at least one extension.

More to the point - there aren't any GL versions above 4.5, or expected in the medium-term future, and all the major drivers already support that. Either the versioning goes up to 13.∞, or one of the software/embedded platforms that you probably don't care about will reach newer GL and there'll be a 14.0. What does that tell you?

[dungeon]

It is 4 drivers per year scheme name it as you like, where year.quarter.git is proposed and year.quarter.point_release is what average "i don't compile" Joe should use

[geearf]

the difference from 13.0.1 to 13.1 is a bit greater and that if they went to 14.0 (not as a date-based thing), that would be even more significant.

Not necessarily, it depends on, if you're using the driver that warranted the version switch or not. If you're not it's about the same.
And I don't believe it would tell you much about performance improvements or alike.

Usually, anyway. Definitely more useful than me trying to figure out how much work they might have done in a given timeframe when looking at a date-based version.

Not by much I'd say.
Not that I'm a fan of that kind of versioning scheme, but a good point is to easily know which dependencies you need for older builds assuming the whole stack follows the scheme... With the previous scheme how do you know what llvm you need for 15.5? But with year.month for all you find it quickly, which is helpful when I try to rollback to older builds to find issues in the stack.

That said, I did word my previous reply too strongly. I dislike the idea, but I did make it sound like it's more of an issue than it actually is.

Agreed

[Hibbelharry]

If you consider just Features, a date based Versioning with fixed Releasedates doesn't make that much sense. But if you consider the flow of small improvements and bugfixes which is always happening, it makes sense to get these out in a timely manner. Look at the whole picture, not just Features.