Mesa's DRM Library Looking To Change Its Versioning Scheme

[phoronix]

Phoronix: Mesa's DRM Library Looking To Change Its Versioning Scheme

Mesa's DRM library could soon be shifting to a date-based versioning scheme similar to what is already employed by Mesa itself (year.release) and the X.Org Server is also looking at similar versioning...

http://www.phoronix.com/scan.php?page=news_item&px=Libdrm-19-Versioning-Scheme

[cybertraveler]

Seeing a date is useful, but not nearly as useful as Semantic Versioning: https://semver.org/

A semver (and similar) version string, communicates to the user/dev a lot of useful information. It also encourages the software/library developer to put effort into producing a stable experience for the users of it. You provide a service to the users and the version number and API is the interface to your service.

If you're on a regular release model where every X months you deliver a build that has breaking changes, then you could use a hybrid of the two. IE do:

YEAR.MONTH.MINOR.PATCH

So if they released this month it would be: 2019.10.0.0. If they rolled out a bug fix for that it would be 2019.10.0.1. If they rolled out a fully backwards compatible improvement it would be: 2019.10.1.0. If their major release schedule is every six months, then the next major release would be: 2020.04.0.0

So effectively it would be semver, but with two major version numbers which are adjusted based on the calendar instead of incrementing by one each release.

[Delgarde]

So effectively it would be semver, but with two major version numbers which are adjusted based on the calendar instead of incrementing by one each release.

But it doesn't make a lot of sense to use dates for those major versions if you're doing semantics — they're going to change with every release regardless of whether they're backward compatible, unless you're going to stick with the 2019.10 major version for the next five years if you don't break compatibility in that time. And if you're going to do that, there's little point in using a date for the version. The two schemes serve different purposes.

[cybertraveler]

But it doesn't make a lot of sense to use dates for those major versions if you're doing semantics — they're going to change with every release regardless of whether they're backward compatible

Your comment doesn't really make sense, but I think I know what you're trying to say.

Fact is: the devs can choose to retain backwards compatibility within a major release. IE they can make a new release with the same date encoded in the version string and that new release can be fully backwards compatible.

Example:

2019-10.0.0 <- initial release
2019-10.1.0 <- backkwards compatible follow-up release a month later with some new features.

I'm pretty much repeating my original post.

The two schemes serve different purposes.

As far as I can tell, the date based scheme IS just a major version number type scheme that encodes the date of release as the major version number(s) and usually corresponds with a regular release schedule.

Considering the above, I see no reason why semver and the date system can't be combined. If the devs absolutely want the date encoded in the version number, then they can do that but combined it with semver to get benefits of both.

Obviously, if they are combined like I suggested, then the devs are committing to not breaking backwards compatibility within a major version. I think this is a good thing to commit to. Good for the users of the software.

[eydee]

I propose using the Mozilla Scheme™. All commits push the major number by 10. Minor numbers only exist in special cases, but never go beyond .01 in a stable version.

[Vistaus]

I propose using the Mozilla Scheme™. All commits push the major number by 10. Minor numbers only exist in special cases, but never go beyond .01 in a stable version.

So the next update will be Mesa DRM 3 and the one after Mesa DRM 4 even it there are only two small changes?

[eydee]

So the next update will be Mesa DRM 3 and the one after Mesa DRM 4 even it there are only two small changes?

Well, yes in a universe in which 3+10=4. Probably you got confused by the M$ emoticon you put there.

[cybertraveler]

Well, yes in a universe in which 3+10=4. Probably you got confused by the M$ emoticon you put there.

Don't bring Microsoft into this!! They're good with major version numbers! E.g.

XBOX 1 (original)
XBOX 360
XBOX One


... ugh... yeah. :P

[Delgarde]

Considering the above, I see no reason why semver and the date system can't be combined. If the devs absolutely want the date encoded in the version number, then they can do that but combined it with semver to get benefits of both.

The problem is that if the year is the major version and the package doesn't break compatibility often, then in 2029 we might still be using libdrm-2019 version... at which point the date part is essentially meaningless and you might as well just use a simple rarely-incrementing number. Worse, you might have old and new branches still in use, such that in 2029, you might see both 2019 and 2024 versions, both of which appear ancient but are actually still actively maintained.

If you _did_ combine them, the solution would probably be to reverse them — use an incrementing number for the major version (representing the actual API version), and the date for the minor versions... e.g. libdrm 1.2019.10 vs 2.2019.11...

[Delgarde]

If you _did_ combine them, the solution would probably be to reverse them — use an incrementing number for the major version (representing the actual API version), and the date for the minor versions... e.g. libdrm 2.2019.10...

In fact, reading the thread, it sounds like that's actually been proposed due to the implications of regularly changing the major version... keep the major version at 2, use the year as the minor version, and an incremental patch version.