Please plan for what happens to SOVERSION when minor/micro version has 2 digits about dxvk

[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.