On 20 March 2017 at 12:25, René Dudfield <renesd@xxxxxxxxx> wrote:The stronger evidence of tests passing, and no concrete theoretical reasons presented on why it can't be compatible suggests to me that it can be done.I don't know a lot about SDL, but the transition sounds like a big change. And my experience is that any big change inevitably makes things break. People will rely on undocumented, untested features, and things that aren't features at all but just happen to work. There are some old stories about the lengths Microsoft went to for backwards compatibility in Windows, which included checking when a certain popular game was started, and then emulating an old bug which that game happened to rely on. I don't think we're going to be doing that sort of thing.
I also don't see the advantage of having one version of pygame that can be built with two different versions of SDL. When people install it, they're getting one or the other version of SDL, not both. If they install it with SDL 1, they don't benefit from the SDL 2 support. If they install it with SDL 2, there's just as much risk of incompatibility as if they had to install a different version or different package for pygame with SDL 2. And recompiling to switch between the two is harder than simply running 'pip install pygame<2'.
This (supporting both SDLs in the same pygame release) is a separate question from making pygame API compatible when it moves to SDL 2 by default. That's an easier case to make - though I think there's also a case for letting pygame 1.x go quietly into the sunset supporting games already built for it, and making pygame2 for new games with some API breakage.