native: Please plan for what happens to SOVERSION when minor/micro version has 2 digits

[smcv]

A follow-up for #3834:

dxvk_so_version currently results in a library name like ….so.0.231 for version 2.3.1. The SOVERSION for each new version needs to compare higher than all old versions, when using a version-aware comparison like strverscmp() or dpkg --compare-versions or similar (which compares them as tuples of integers, rather than as floating-point).

At the moment the parts of the version number are just concatenated, so 2.3.1 becomes .so.0.231, and 2.3.10 would be .so.0.2310, but then 2.4.0 would be .so.0.240 which compares less than 0.2310 - not what's wanted here.

If the intention is to keep the current version numbering scheme (major/minor/micro with no particular semantic meaning) then probably the simplest solution would be zero-padding to some width larger than you expect to reach, like .so.0.2003002 for version 2.3.2, .so.0.2003010 for 2.3.10, .so.0.2011006 for 2.11.6, all of which compare greater than 0.231.

Or if you'd prefer, the major/minor could be combined into one integer with zero-padding and the micro could be its own SOVERSION component, like .so.0.2003.2 for 2.3.2 (which would still compare greater than 0.231 as desired).

(This matters because mechanisms like ldconfig and the Steam Linux Runtime use the equivalent of strverscmp() on the realpath() of the library to decide which of multiple copies is newest, and then prefer using that one.)

[smcv]

cc @flibitijibibo

[flibitijibibo]

I guess to continue the topic of the version numbers, since it's mostly vibes anyway should this maybe transition to YY.MM(.DD) versioning?

[smcv]

Pure date-based versioning makes a lot of sense if you're 110% confident that there will never be a breaking change ever again. I realise that the actual DirectX-flavoured parts of DXVK can't really break compatibility anyway, because the whole point is that they follow what Microsoft does in the DirectX API, but I don't think it's necessarily possible to say the same about the WSI layer.

I personally like to leave a major version available as an escape hatch to be able to either make an incompatible change (like the way GTK, Qt, SDL major versions work), or change the versioning scheme (if you discover that actually the versioning scheme was a mistake and you want to do something different). That's why steam-runtime-tools is 0.YYYYMMDD.R, for instance: we'd bump the leading 0 to a 1 if we either did a compatibility break, or decided to switch from date-based to some other scheme (semver or whatever). I think of it as being like the epoch in packaging systems like dpkg/RPM: we don't necessarily intend to ever use it, but better to have it and not need it than to need it and not have it.

Date-based versioning without a non-date-based prefix tends to lead to numerically large version numbers, from which the only backwards-compatible direction left available to you is a very large major version like the ones seen in Chromium, Firefox, systemd.

YY.MM(.DD)

If there will ever be a situation where you find that you need to do a hotfix release - possibly more than one on the same day! - then the last component will need to be something you can increment freely without being constrained by it having other meaning.

[flibitijibibo]

The date system is pretty much how FAudio does it: the version is mostly a name while semantically the "major" version is always 0:

https://github.com/FNA-XNA/FAudio/blob/master/CMakeLists.txt#L31

So it would appear to be 24.06, but technically it's 0.24.06. We've done patch updates before (even on the day of release, meaning we've had 24.06.01 for example) and typically they only show up in GetVersion() rather than in the soname. If we ever break then we update the ABI version and continue with the dates as usual.

[doitsujin]

Just went with the zero-pad option.