upgrade our vendored libjxl to v0.7.2, 0.8.4 or 0.9.4?

[sezero]

Should we upgrade our vendored libjxl to v0.7.2, 0.8.4 or 0.9.4? (0.10.x
or 0.11.x would be too new - our tests are failing with those releases.)

The mainstream doesn't seem to be maintaining 0.6.x, the newer branches
received security fixes in late Nov. 2024.

For distros: Fedora EPEL (Extra Packages for Enterprise Linux) 8 and 9
are at 0.7.0, so is Debian stable.

If we do this though, Xcode (and possibly MSVC) projects will need some
surgery.

[madebr]

Do you track the state of all dependencies? I'd prefer to update all dependencies of all satellite libraries in one go every x months/years.

[slouken]

We probably should, and we should probably track what's in distributions. It looks like Debian stable is at 0.7 and debian unstable is at 0.10. I'm concerned that 0.10+ has different image output, but realistically we should probably jump to that and update the tests because that's what the developers are working on and what will be in the next stable distributions.

[sezero]

Do you track the state of all dependencies? I'd prefer to update all dependencies of all satellite libraries in one go every x months/years.

Once in a while, yes, and if I'm aware of some important update in a 3rd party lib which is our dependency, then I update it. I don't usually upgrade though: E.g. for SDL2, I've been keeping libwebp at 1.0.3 (with updates / security fixes applied) and libtiff at 4.2.0 (the same way): no real need for an upgrade. For SDL3 though, I'd usually prefer latest maintained version if it were up to me.

We probably should, and we should probably track what's in distributions. It looks like Debian stable is at 0.7 and debian unstable is at 0.10. I'm concerned that 0.10+ has different image output, but realistically we should probably jump to that and update the tests because that's what the developers are working on and what will be in the next stable distributions.

For SDL3_image, upgrading to 0.11.x is reasonable I think. For SDL2_image, I don't know.

Either way, libjxl's own dependencies are monsters to deal with as they are. Won't be pretty I guess.

[slouken]

Do you track the state of all dependencies? I'd prefer to update all dependencies of all satellite libraries in one go every x months/years.

Once in a while, yes, and if I'm aware of some important update in a 3rd party lib which is our dependency, then I update it. I don't usually upgrade though: E.g. for SDL2, I've been keeping libwebp at 1.0.3 (with updates / security fixes applied) and libtiff at 4.2.0 (the same way): no real need for an upgrade. For SDL3 though, I'd usually prefer latest maintained version if it were up to me.

Agreed, let's go ahead and do that.

We probably should, and we should probably track what's in distributions. It looks like Debian stable is at 0.7 and debian unstable is at 0.10. I'm concerned that 0.10+ has different image output, but realistically we should probably jump to that and update the tests because that's what the developers are working on and what will be in the next stable distributions.

For SDL3_image, upgrading to 0.11.x is reasonable I think. For SDL2_image, I don't know.

Either way, libjxl's own dependencies are monsters to deal with as they are. Won't be pretty I guess.

Let's leave it alone for SDL2_image and upgrade to latest in SDL3_image.

[sezero]

upgrade to latest in SDL3_image.

I created a v0.11.1-SDLbranch in our libjxl fork. The cmake'ry and rest would probably be handled better by @madebr.

Let's leave it alone for SDL2_image

Not 100% comfortable with staying at 0.6.1, but really OK.

[slouken]

upgrade to latest in SDL3_image.

I created a v0.11.1-SDLbranch in our libjxl fork. The cmake'ry and rest would probably be handled better by @madebr.

Let's leave it alone for SDL2_image

Not 100% comfortable with staying at 0.6.1, but really OK.

Feel free to upgrade it to 0.7 if you want.

[sezero]

Feel free to upgrade it to 0.7 if you want.

Created a v0.7.2-SDL branch for it

[sezero]

Updated brotli and highway submodules in both v0.7.2-SDL and v0.11.1-SDL

[sezero]

The following commits of ours from the old v0.6.1-SDL branch might
be still needed, but they do not apply cleanly, and they obviously
need updating and / or changing for new v0.7.2-SDL and v0.11.1-SDL
branches: Leaving those to @madebr and possibly @slouken.

libsdl-org/libjxl@4addaa4
libsdl-org/libjxl@8858f35
libsdl-org/libjxl@3508c0c
libsdl-org/libjxl@d456eed
libsdl-org/libjxl@19cfa74