Proposal: move sdl*-compat into SDL3

[slouken]

I know we've talked about this before, but what do you guys think about moving the compat projects into the main SDL tree?

Currently if we make a change in SDL, we have to go to a separate repository to make the corresponding change to the compat libraries, which honestly, @sezero is awesome at, but @icculus and I aren't as diligent about.

Pros:

• SDL3 and corresponding compat changes can be a part of the same changelist and reverted/adjusted atomically
• We can run SDL2 and SDL1 tests in CI to verify we haven't broken any functionality with SDL3 changes
• An SDL release will automatically contain the matching compat libraries

Cons:

• We can't have separate compat library releases
• Matching SDL release is less important once we freeze the ABI

Reading this list, there isn't anything that we can't do with a little more diligence and fancy CI scripts, so maybe it's not worth changing.

@libsdl-org/a-team, @smcv, thoughts?

[icculus]

I do think it would be very useful until 3.2.0 ships, as we are still continually changing things, and then it would be a hindrance forever more, so I still think they should remain separate.

The release cadences will be very different. It still makes sense to do sdl12-compat releases, every few months, but it's at the point where it's becoming "oh, we worked around issues specific to a single game," which is a good place to be. My (naive!) hope with sdl2-compat is that once SDL3 locks down, we'll spend a few point releases fixing up oversights, and then it'll largely be left alone, since the magic it's trying to accomplish is much less complex and nasty than what sdl12-compat requires.

[sezero]

Agreeing with Ryan: they should be separate.

* We can run SDL2 and SDL1 tests in CI to verify we haven't broken any functionality with SDL3 changes

Maybe add cron jobs to CI to run tests?

[madebr]

An extra ci job (or step on Windows/Linux/Macos) can be added to the SDL3 repo that downloads SDL2-compat, builds it, and runs its tests.

[Kontrabant]

Another agreement that they should stay separate. As Ryan said, once SDL3 is API/ABI stable, the compatibility libraries shouldn't really need to be touched outside of the occasional bug fix or app-specific workaround.

An extra ci job (or step on Windows/Linux/Macos) can be added to the SDL3 repo that downloads SDL2-compat, builds it, and runs its tests.

Along the lines of what sezero said, would it make sense to just run a build test for the compat libraries once per day or so? The current CI pipeline can already take quite a long time to run.

[slouken]

An extra ci job (or step on Windows/Linux/Macos) can be added to the SDL3 repo that downloads SDL2-compat, builds it, and runs its tests.

Okay, let's do this, and I'll close this issue.

Thanks for the feedback everyone!

[smcv]

I agree with what everyone else said, but there is an additional reason I would like SDL3 and sdl2-compat to be separate: from a packager point of view.

I've already packaged SDL3 and its _image, _mixer and _ttf satellite libraries for Debian experimental, and when it gets to an API- and ABI-stable status, I'll want to push it to testing/unstable for wider use. Initial packaged versions will be used by no games at all or by a handful of recently-updated games, so they are low risk to iterate on from a packager's point of view.

sdl2-compat is going to be a higher-risk thing to work with, because there's a much broader range of games and non-game packages (qemu!) where it could cause regressions, so we will want to be a lot more cautious with that. I think distros will want to ship it the same way we did for sdl12-compat: first as an opt-in non-default that you have to use via LD_LIBRARY_PATH or SDL_DYNAMIC_API, then as something that early adopters can install as their system's default SDL2 but without affecting the distro as a whole, and finally flipping the switch to replace SDL2 with sdl2-compat distro-wide for all users. And, in distros that have a bleeding-edge probably-doesn't-work branch like Debian experimental, we'll want to try each of those steps in experimental or equivalent before committing to it.

Obviously sdl2-compat has a massive head start compared with sdl12-compat, so I hope that we can speedrun those steps instead of having them a year or more apart like we did for sdl12-compat; but I think we will still need to go through them, and if we can do that "out of phase" with SDL3, then that will minimize disruption to SDL3 and allow us to keep packaging new releases promptly.

[smcv]

we will want to be a lot more cautious with [sdl2-compat]

Doubly so for the Steam Runtime of course :-)

[slouken]

Yep, agreed. :)