search

py-sdl / py-sdl2

Python ctypes wrapper around SDL2
Other
304 stars 49 forks source link

Unit test expects SDL version to stay 2.0.x forever #228

Closed smcv closed 2 years ago

smcv commented 2 years ago

What doesn't work?

sdl2/test/version_test.py has:

def test_SDL_GetVersion():
    v = sdl2.SDL_version()
    sdl2.SDL_GetVersion(ctypes.byref(v))
    assert type(v) == sdl2.SDL_version
    assert v.major == 2
    assert v.minor == 0
    assert v.patch >= 5

This assumes that all SDL versions compatible with SDL 2.0.0 will be versioned 2.0.x.

However, the stable version after SDL 2.0.22 is going to be 2.24.0, with prereleases identifying themselves as 2.23.x. See the documentation for details.

The motivation for this change was that in the previous numbering scheme, the .0. was essentially useless (if it only increases on incompatible changes, then it's redundant with the major version), and there was no way to signal bugfix-only releases to fix regressions or other serious bugs without adding new features.

Next time SDL breaks compatibility, the new/incompatible version will call itself SDL 3, with filenames likely to look like libSDL3.so.0 or SDL3.dll.

How To Reproduce

Upgrade SDL2 to a git snapshot or a future stable release, then run py-sdl2's unit tests. You can see this happen in Debian's CI system when it tries to run tests against a libsdl2 git snapshot from experimental, as listed in https://ci.debian.net/packages/p/pysdl2/unstable/amd64/:

self = <sdl2.test.version_test.TestSDLVersion object at 0x7fc0ba1caac0>

    def test_SDL_GetVersion(self):
        v = version.SDL_version()
        version.SDL_GetVersion(ctypes.byref(v))
        assert type(v) == version.SDL_version
        assert v.major == 2
>       assert v.minor == 0
E       assert 23 == 0
E         +23
E         -0

Platform (if relevant):

smcv commented 2 years ago

Secondary libraries like SDL_image, SDL_mixer and SDL_ttf are also changing their versioning scheme in the same way: the next stable releases after SDL_image 2.0.5, SDL_mixer 2.0.4 and SDL_ttf 2.0.18 are expected to be 2.6.0, 2.6.0 and 2.20.0 respectively.

smcv commented 2 years ago

Secondary libraries like SDL_image, SDL_mixer and SDL_ttf are also changing their versioning scheme in the same way

The py-sdl2 tests have similar assertions about those libraries, which have the same problem, and are also failing in Debian's CI when run against git snapshots of SDL_image and so on. New releases of those libraries are expected to happen relatively soon.

SDL_net is also going to go from 2.0.1 to 2.2.0, although I don't know whether py-sdl2 has bindings or tests for that, and I don't think there are any plans to release SDL_net 2.2.0 soon.

a-hurst commented 2 years ago

Hi @smcv, thanks for creating an issue for this! I noticed the PR for the version scheme change (which is definitely an improvement over the old one), but I completely forgot that my unit tests always assumed the middle number would be zero. I'll fix this in time for the next release, as well as make sure PySDL2's internal handling of version numbers is ready for the change.

smcv commented 2 years ago

229 doesn't actually fix this: it still asserts that v.patch >= 5 or similar, but that's not going to be true in 2.24.0.

I have a branch nearly ready which compares version numbers as tuples, instead.