• IchorDev (7/7) Apr 04 2023 With SDL3's release getting closer, I've been thinking that
• =?UTF-8?Q?S=c3=b6nke_Ludwig?= (12/20) Apr 06 2023 There were some issues with (deimos-)OpenSSL due to the fact that many

IchorDev <zxinsworld gmail.com> writes:

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?

=?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:

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.