Closed slouken closed 2 months ago
Off-topic: It maybe early yet, but the version requirement in sdl2-compat is broken as it is: we require sdl >=3.0.0, but we will be requiring >= 3.2.0 when sdl3 is frozen. (Even sdl3 headers' since
fields are incorrect, because they spell 3.0.0...) With sdl3 still a fast moving target, can't we do something about that? I.e. Always increase the micro version of sdl3 whenever an api/abi change occurs and update sdl2-compat accordingly?
Off-topic: It maybe early yet, but the version requirement in sdl2-compat is broken as it is: we require sdl >=3.0.0, but we will be requiring >= 3.2.0 when sdl3 is frozen. (Even sdl3 headers'
since
fields are incorrect, because they spell 3.0.0...) With sdl3 still a fast moving target, can't we do something about that? I.e. Always increase the micro version of sdl3 whenever an api/abi change occurs and update sdl2-compat accordingly?
Right now we require the latest version of SDL3. Once we have a frozen ABI, we'll set it to that version and any future API changes in SDL will generate a version bump that we can match as needed.
Right now we require the latest version of SDL3.
Yes, but sdl2-compat doesn't know that. Take yesterday's sdl2-compat build and run against today's sdl3 with bool changes (or vice versa), and see your pc explode.
Right now we require the latest version of SDL3.
Yes, but sdl2-compat doesn't know that. Take yesterday's sdl2-compat build and run against today's sdl3 with bool changes (or vice versa), and see your pc explode.
Don't do that. :) Seriously, main code in projects depend on main code in other projects. Once we have a release, we'll have proper dependencies and versioning.
OK then :))
Looks OK, as far as I can see.