April 04, 2023

With SDL3's release getting closer, I've been thinking that perhaps the next major release of BindBC-SDL (2.0.0) should axe SDL2 compatibility in favour of nicer SDL3 bindings.
This would be different to my earlier plan, which was for BindBC-SDL 2.0.0 to simply remove a few deprecated symbols, but ultimately maintain SDL2 support.

Any thoughts?

April 07, 2023
Am 04.04.2023 um 16:29 schrieb IchorDev:
> With SDL3's release getting closer, I've been thinking that perhaps the next major release of BindBC-SDL (2.0.0) should axe SDL2 compatibility in favour of nicer SDL3 bindings.
> This would be different to my earlier plan, which was for BindBC-SDL 2.0.0 to simply remove a few deprecated symbols, but ultimately maintain SDL2 support.
> 
> Any thoughts?

There were some issues with (deimos-)OpenSSL due to the fact that many different "major" versions are floating around and you'd usually want to use the OS provided version. Splitting up the bindings into different version ranges would require to select the proper version manually at build time, so instead it supports all of them at the same time and by default selects the installed one at build time.

However, for a project like SDL, I think splitting it up into different major version ranges is probably fine, since *probably* nobody is going to implement multiple code paths for different versions there, just to support different OS pre-installed versions. Since it makes maintenance much more streamlined, I'd always favor that as the default.