An SDL pre-release build is now available for download:
This is different from a normal pre-release build since we’re not about to release the next stable version, but we’ve made significant changes to the versioning system and CMake support and would like to make them available mid-development cycle to get feedback.
Please report any issues at:
It’s ironic that you’re breaking the semantics of the SDL versioning scheme to introduce semantic versioning.
This will break stuff, for example this: Linux-app-wrapper/wrapper.c at 5424fffba0a1825a0f8164a685d2707bd26b1d01 · DanielGibson/Linux-app-wrapper · GitHub
IMO this change should’ve been done for SDL3, not now.
Except that the documentation of SDL_version has in fact always been virtually identical to that of semantic versioning: MAJOR.MINOR.PATCH. Compare the names and descriptions of the fields between the two documents if you don’t believe me!
So the problem has been - as I’ve pointed out many times - that the way SDL version numbers have been used in practice disagrees with its own documentation! Either changing the numbering scheme to match the documentation, or changing the documentation to match the numbering scheme, is way overdue.
No idea how that information got there, but it wasn’t actually used that way - obviously, which is why MINOR wasn’t increased in > 8 years, or why 1.3 was incompatible to 1.2 (IIRC), or in discussions in the bug tracker until relatively recently API/ABI-breaking changes were talked about as “for 2.1” (until it was decided that the next version with breaking changes should be SDL3, which is totally fine and doesn’t require changing the versioning scheme of 2.x)
As I said, one solution would be to change the documentation to match the de-facto numbering scheme, but either way something has to change. It’s annoying, to say the least, when the documentation can’t be trusted. I’m one of those old-fashioned programmers who writes code based on the documentation, not what seems to work in practice. 
Personally I’d prefer to see the numbering changed to match the documentation, because from the perspective of a developer using SDL2 it’s of practical value to know if a new version is just a bug fix, or introduces new functionality (which ought not to be a breaking change, but frequently is). Currently it’s not possible to determine that from the version number.
Yeah, the documentation should definitely match the real behavior and should’ve been changed.
No idea if there’s any chance of reverting the versioning change, but I at least wanted to note that it’ll cause problems as long as it’s just a prerelease, before it’s definitely too late (and yes, I’ve used the wrapper I linked above in a commercial game that might not get updated).
Also note that I don’t want to discuss the pros and cons of semantic versioning in general - it seems generally sane, I don’t care, I wouldn’t mind it for SDL3.
But changing the versioning (and thus breaking the de-facto semantics of the versioning scheme used for at least 8 years, arguably for >20 years) in an update that’s supposed to be fully backwards compatible is IMHO a bad idea.
I don’t mean to be unkind, but you wrote that code knowing that it relies on Undocumented Behavior, indeed behavior contrary to the documentation! You took a risk, and if you now come unstuck as a result you cannot really complain.
As far as I am concerned, so long as macros like SDL_VERSION_ATLEAST continue to work reliably, the change that Sam is proposing is absolutely fine.
What we’ve discovered over the last 10 years is that we can reliably keep the API stable such that you don’t need to do the kind of version checking you have here. The next ABI break will use a different library name such that existing applications won’t accidentally link with it.
Cheers,