How does this change to the versioning system handle old versions of SDL still out in the wild?

How does this change to the versioning system handle old versions of SDL still out in the wild?

No change. All the stable versions of SDL2 released before 2.24.0 were of the form 2.0.x, where 2.0.x is backwards-compatible with 2.0.y, for any x >= y. It is still true that 2.0.x is backwards-compatible with 2.0.y for any x >= y.

What has changed is that before 2.24, SDL upstream didn't specify whether 2.x.a is compatible with 2.y.b, where x != y. Before this MR, pygame pessimistically assumed that a minor version change is a compatibility break, similar to the way SDL 1 worked (SDL 1.2 was incompatible with SDL 1.3).

Since 2.24, SDL upstream is declaring that all (stable) versions of-lSDL2 (sdl2.pc,libSDL2.so on Linux,SDL2.lib/SDL2.dll on Windows, etc.) are going to be backwards-compatible with older stable versions of-lSDL2. Next time there is an intentionally incompatible version, SDL upstream is now promising that it will be renamed to SDL 3 (sdl3.pc, linked using-lSDL3,libSDL3.so on Linux,SDL3.lib/SDL3.dll on Windows, etc.) and generally behave like a separate library, similar to what happened at the jump between SDL 1 and SDL 2.

I see pygame usessdl2-config on Unix. Another consequence of what I said in my previous comment is: SDL upstream is now saying thatsdl2-config will always find a version of SDL 2 that is backwards-compatible with all older stable versions of SDL 2. Next time there is an intentional incompatible change, the library will be renamed to SDL 3, meaningsdl2-config will either be renamed tosdl3-config or removed in favour ofpkg-config sdl3 (see#3429).

I've tested this patch on windows (by replacingSDL2.dll with an older one) and it works as intended

I'm not a pygame maintainer or contributor, but this looks good to me.