Make releases please for make possible packaging in distros repositories

[Kerrung]

No description provided.

[icculus]

I think we'll do an initial official release soon!

[skitt]

FTR, I’ve started packaging snapshots in Debian: https://tracker.debian.org/pkg/sdl12-compat. There are two packages, one which is co-installable with “regular” SDL 1.2, the other which replaces it — the idea being to allow interested packages (e.g. for Quake 4) to pull in sdl12-compat, without forcing everything to use it.

[Kerrung]

And make it please available in AUR.

[traversaro]

Thanks a lot for all the work on sdl12-compat! I am trying to understand if there could be interested and how to use sdl1-compat as the part of the conda-forge, see conda-forge/sdl-feedstock#5 .

I was curious about two aspects one aspect:

• What will be the versioning scheme of sdl12-compat ? It will have a 1.2.16 release to act as a successor of sdl1.2 , or will have an indipendent versioning that will start from another value?
• Are sdl12-compat and sdl1.2 meant to be ABI compatible or not?

Thanks in advance!

[traversaro]

• Are sdl12-compat and sdl1.2 meant to be ABI compatible or not?

Actually the answer to this is already in the README (and it is yes), sorry for the noise.

[icculus]

It will have a 1.2.16 release to act as a successor of sdl1.2 , or will have an indipendent versioning that will start from another value?

It will report itself as 1.2.50, to signify it's still the 1.2 API but there's no question it's not a minor patch release of classic SDL 1.2.

[traversaro]

It will have a 1.2.16 release to act as a successor of sdl1.2 , or will have an indipendent versioning that will start from another value?

It will report itself as 1.2.50, to signify it's still the 1.2 API but there's no question it's not a minor patch release of classic SDL 1.2.

Perfect, thanks!

[icculus]

I guess since we're getting picked up by distros, we should do a formal sdl12-compat release. Is there anything we want to change before we tag an official 1.0.0 (1.2.50?) release? @sezero? @sulix? @Conan-Kudo?

@slouken: how do we want to do this? Just tag it and let GitHub provide a tarball from that tag? Or something more formal?

[slouken]

Let's just version and tag it. We might want to provide binaries on the website for Windows and Mac

[sezero]

• Functionality to fix / handle better / verify:

  • Windows SDL_SetModuleHandle, SDL_RegisterApp, SDL_UnregisterApp stuff:
    Port to Windows #8 (comment)
    Maybe also seee: missing SDL_main functionality #106
  • Verifying fake-cdrom code / audio init/deinit stuff:
    cdrom code #32 (comment)

• Issues to fix:

  • Dynamite Jack hangs at the title screen #133
  • Linapple emulator runs without graphics #110
  • not work in opendingux? #104
  • And maybe Quake IV lacks stencil shadow volumes #126

[sezero]

Also for macOS: Is there a way to handle deployment target (10.6 for x86/x64, 11.0 for aarch64) in cmake?

[sulix]

There are a bunch of FIXME()s that it'd be nice to get to: even if we don't get to fix them, it'd be nice to have some of them only trigger when they're more likely to indicate an actual problem with the running application. Now that FIXMEs are disabled by default, it's not as confusing as it could be, though.

We might also want to document some of the cases where sdl12-compat won't work: particularly with programs which depend, e.g., on accessing X11 directly (including a whole bunch of OpenGL extension loaders / libcgGL which use GLX) if you're running under wayland, or things which break with the OpenGL scaling.

That being said, if Fedora is already using this reasonably successfully as the default, that's a pretty good sign that none of the remaining issues are super-critical and need to block a release.

[icculus]

Okay, I'm going to put together a milestone from @sezero's list so we have a formal checklist for a release, and I'll start poking at that once SDL 2.0.18 is out the door.

[icculus]

Also for macOS: Is there a way to handle deployment target (10.6 for x86/x64, 11.0 for aarch64) in cmake?

Kitware's own claim is that you specify -DCMAKE_OSX_ARCHITECTURES='x86_64;arm64' -DCMAKE_OSX_DEPLOYMENT_TARGET=10.6 and it'll do the right thing (set it to 10.6 for x86_64, and 11.0 for the arm64 part). This might be broken for Xcode, but it works with Ninja (and presumably Unix Makefiles).

Said here:

https://gitlab.kitware.com/cmake/cmake/-/issues/22184

(They have an Xcode specific piece of magic mentioned in there too (adding [arch=arm64] to specific settings.))

[icculus]

I split @sulix's comments into new issues and added them and most of @sezero's suggestions to a milestone. The OpenDingux and Linapple ones did not get added because they're on "weird" hardware and we can't currently reproduce the issues, so we won't hold up for those right now.

[smcv]

Since the git snapshots found in e.g. Fedora and Debian already identify themselves as SDL 1.2.50 internally (libSDL-1.2.so.1.2.50), it might actually be better if the first tagged release is identified as 1.2.51. That way, when mechanisms like ldconfig and the Steam Runtime compare the git snapshots currently in Fedora/Debian with the tagged release, the tagged release will "win" and be chosen as the "better" version.

[Conan-Kudo]

Well, sdl12-compat has its own version, and there's the version it pretends to be. I prefer that those versions are different, personally.

So I would vote for it being called 1.0.0 release and leaving the SDL version at 1.2.50.

[smcv]

So I would vote for it being called 1.0.0 release and leaving the SDL version at 1.2.50.

If all versions of sdl12-compat install libSDL-1.2.so.0 -> libSDL-1.2.so.1.2.50, then we cannot look at two different versions (for example one from the Steam Runtime and one from the host system) and say which one is newer.

If different versions install as libSDL-1.2.so.0 -> libSDL-1.2.so.1.2.51 and libSDL-1.2.so.0 -> libSDL-1.2.so.1.2.57, then we can look at those two symlinks and say with high confidence that the second one is the newer one.

The Steam Runtime relies on being able to do that comparison: if it cannot, then it has to make an arbitrary choice of host system or Steam Runtime, and assume that version is "probably" newer. (Currently it assumes libraries on the host system are newer, with a few targeted exceptions.)

When /sbin/ldconfig updates the system dynamic linker cache ld.so.cache, it uses the same logic to determine which library is newer.

[slouken]

We'll match the SDL 1.2 ++ version for our release. There's no reason to have sdl12-compat at 1.0 instead of 1.2.x, and having the version be higher than the 1.2 release will be better for distros.

[icculus]

LAST CALL FOR 1.2.50.

The latest in revision control fixes all the major known issues, afaik, and I've tested it on Windows, Mac, and Linux.

Unless there are concerns, we're tagging the current revision as an official 1.2.50 release.

Speak now if we should delay!!

[Conan-Kudo]

I'm fine with this, that will let me update to a tagged release in Fedora and CentOS Stream.

cc: @wtay

[sezero]

#104 and/or #110 maybe?

[icculus]

#104 and/or #110 maybe?

Both are corner cases on weird hardware. Not invalid, but not worth holding up a release for.

(And also possibly the problem is that SDL2 became incompatible with these devices while classic 1.2 still worked.)

[sezero]

OK.

[smcv]

Unless there are concerns, we're tagging the current revision as an official 1.2.50 release

I'm testing this for possible inclusion in the Steam Runtime now. Only one issue found so far (#160) , and it's really minor (a build issue with ancient OpenGL libraries) and could easily wait for a subsequent release.

As I mentioned in #53 (comment), if possible I'd prefer the first release to be labelled as something strictly greater than 1.2.50 (1.2.51 would be ideal), so that we can distinguish it from snapshots older than the first release (which identify themselves as 1.2.50).

[sezero]

As I mentioned in #53 (comment), if possible I'd prefer the first release to be labelled as something strictly greater than 1.2.50 (1.2.51 would be ideal), so that we can distinguish it from snapshots older than the first release (which identify themselves as 1.2.50).

@icculus: If version number is bumped, please remember to update
Makefile.darwin, Makefile.linux, Makefile.os2, Makefile.w32, and
version.rc for it, along with CMakeLists.txt.

[Conan-Kudo]

I would prefer the version to be 1.2.50 since that would indicate a finalized release of what this has developed into. And we have had no releases before now anyway.

[slouken]

Some distributions are already shipping the pre-release code as 1.2.50. We should bump this to 1.2.52 for release. @sezero, would you like to do the honors?

[Conan-Kudo]

Who is shipping as 1.2.50? It's not Fedora or Debian, that's for sure:

• Fedora is shipping as 0.0.1~git: https://src.fedoraproject.org/rpms/sdl12-compat
• Mageia is shipping as 0.0.1~git: https://svnweb.mageia.org/packages/cauldron/sdl12-compat/current/SPECS/sdl12-compat.spec?view=markup
• Debian is shipping as 0.0~git: https://packages.debian.org/source/sid/sdl12-compat
• Ubuntu is shipping as 0.0~git: https://packages.ubuntu.com/source/jammy/sdl12-compat

Repology confirms that no one is shipping it as 1.2.50: https://repology.org/project/sdl12-compat/versions

[Conan-Kudo]

I've submitted #161 to rewire project versioning to match what we've decided here so far.

[slouken]

Who is shipping as 1.2.50? It's not Fedora or Debian, that's for sure:

• Fedora is shipping as 0.0.1~git: https://src.fedoraproject.org/rpms/sdl12-compat
• Mageia is shipping as 0.0.1~git: https://svnweb.mageia.org/packages/cauldron/sdl12-compat/current/SPECS/sdl12-compat.spec?view=markup
• Debian is shipping as 0.0~git: https://packages.debian.org/source/sid/sdl12-compat
• Ubuntu is shipping as 0.0~git: https://packages.ubuntu.com/source/jammy/sdl12-compat

Repology confirms that no one is shipping it as 1.2.50: https://repology.org/project/sdl12-compat/versions

Ah, I thought Fedora had shipped as 1.2.50. In that case, we should be good.

[sezero]

Are we keeping 1.2.50 as is, or are we bumping now?

[Conan-Kudo]

Who is shipping as 1.2.50? It's not Fedora or Debian, that's for sure:

• Fedora is shipping as 0.0.1~git: https://src.fedoraproject.org/rpms/sdl12-compat
• Mageia is shipping as 0.0.1~git: https://svnweb.mageia.org/packages/cauldron/sdl12-compat/current/SPECS/sdl12-compat.spec?view=markup
• Debian is shipping as 0.0~git: https://packages.debian.org/source/sid/sdl12-compat
• Ubuntu is shipping as 0.0~git: https://packages.ubuntu.com/source/jammy/sdl12-compat

Repology confirms that no one is shipping it as 1.2.50: https://repology.org/project/sdl12-compat/versions

Ah, I thought Fedora had shipped as 1.2.50. In that case, we should be good.

I wouldn't do that, as I was in the camp of restarting the project version. 😉

[Conan-Kudo]

Are we keeping 1.2.50 as is, or are we bumping now?

I think we're keeping 1.2.50 as-is.

[smcv]

Who is shipping as 1.2.50?

Everyone, if you look at the actual shared library and not just at the packaging metadata. For example, on Debian:

$ readlink -f /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
/usr/lib/x86_64-linux-gnu/sdl12-compat/libSDL-1.2.so.1.2.50

The basename of the realpath() of the shared library is how ldconfig and the Steam Runtime decide which version of a library is newer.

My request is for prerelease snapshots to compare strictly older than the shipped release, so that when we have:

• Fedora 35: a snapshot labelled 0.0.1~git.20211125 in metadata but internally named libSDL-1.2.so.1.2.50
• Steam Runtime: the final release labelled 1.2.52 and internally named libSDL-1.2.so.1.2.52 (or whatever version is most aesthetically appealing, as long as it's strictly greater than 50)

we will use the Steam Runtime's version because 52 > 50.

It's too late to achieve this by making prerelease snapshots compare older, so the only way to make it happen is to make the final release compare newer.

[smcv]

We should bump this to 1.2.52 for release

Please only commit this in the version that is literally released, otherwise we will have the same problem again, where a pre-release snapshot compares equal to the release and things like ldconfig and the Steam Runtime cannot tell the difference.

[Conan-Kudo]

But we don't want Steam's version to win? Also, Steam Runtime is currently not shipping sdl12-compat, so this shouldn't actually matter.

[skitt]

But we don't want Steam's version to win? Also, Steam Runtime is currently not shipping sdl12-compat, so this shouldn't actually matter.

I don’t think we want the Steam version to have its own version. The problem currently is that the existing libraries advertise themselves as 1.2.50, so 1.2.50 in the Steam runtime (or anywhere else) isn’t determinably different from pre-releases that have been shipping for a while. Bumping to 1.2.52 or whatever in the release commit exactly ensures that 1.2.52 is a known quantity, and whether Steam uses its own runtime copy or the system’s doesn’t matter then.

[Conan-Kudo]

But this is theorycrafting since Steam is shipping the real SDL 1.2, not this.

[skitt]

But this is theorycrafting since Steam is shipping the real SDL 1.2, not this.

I would call it planning ahead.

[Conan-Kudo]

Well, if we go by the library string for versioning, sdl12-compat is going to be higher than anything any Steam Runtime ships today. And we basically always want the host version of SDL to win over any other version. So even releasing 1.2.50 now as-is means distros that ship sdl12-compat will be fine, SDL Runtime hasn't upgraded to it yet, and when they do, it'll be the normal situation everyone expects.

[skitt]

And we basically always want the host version of SDL to win over any other version.

Not if the host version is a snapshot of sdl12-compat. A user of Ubuntu 21.10 with the sdl12-compat packages installed will have a late June snapshot of sdl12-compat, with no simple way for the Steam runtime or anything else to determine that it’s not the same as the forthcoming release of sdl12-compat.

[slouken]

We'll go with 1.2.52, to keep everything simple.

[sezero]

Some distributions are already shipping the pre-release code as 1.2.50. We should bump this to 1.2.52 for release. @sezero, would you like to do the honors?

We'll go with 1.2.52, to keep everything simple.

Bumped the version to 1.2.52: 030111a

[sezero]

Someone should tag the release I guess, if nothing else is left to do.

How are we going to do the binaries (if any)?

[slouken]

I'll do some more testing today and then tag the release. This release is mostly for Linux distributions so we'll wait and see if anyone needs other binaries.

[slouken]

Released!
https://github.com/libsdl-org/sdl12-compat/releases/tag/release-1.2.52

[sezero]

Released! https://github.com/libsdl-org/sdl12-compat/releases/tag/release-1.2.52

Bumped version to 1.2.53 for future development: cc52691