On Mon, Mar 20, 2017 at 2:27 PM, Thomas Kluyver <tak...@gmail.com> wrote:
> On 20 March 2017 at 12:25, René Dudfield <ren...@gmail.com> 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 understand it's a risk. But from what I've seen, I don't think it's a big one. 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'. > > The big advantage is that it is a much smaller change than something new. - smaller changes reducing risk - the smaller amount of resources needed to get to SDL2 - compatibility for those of us who care about what we've made - SDL1 using people can keep with that for the time being End users will still `pip install pygame` and not care about how we decide to develop the changes. 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. > I guess that is a lot more effort than what I'm suggesting, and provides less benefit. The proposal: - takes work that is mostly done already, and cleans it up - keeps everyones apps working - whilst the work happens, pygame 1.9.x and 1.9.10 are releasable. - provides a base for future improvements - gets extra platform support (SDL2 gives us easier mobile, etc) - keeps everything working whilst the changes are made - reduces future documentation, and packaging work of maintaining two code bases - is less work, and less risky than continuing on from pygame_sdl2 and filling in the missing bits. - has a transition plan for end users, which is do nothing differently.
