search

godotengine / godot-cpp

C++ bindings for the Godot script API
MIT License
1.7k stars 528 forks source link

Add support for `PackedVector4Array` #1456

Closed dsnopek closed 4 months ago

dsnopek commented 4 months ago

Fixes https://github.com/godotengine/godot-cpp/issues/1454

Adds support for PackedVector4Array from Godot PR https://github.com/godotengine/godot/pull/85474

YuriSizov commented 4 months ago

Should this be considered a compatibility breaking change? Without a compatible engine version extensions built with this commit included no longer work, unfortunately. This means all existing official builds of 4.3, I think.

dsnopek commented 4 months ago

The master branch of godot-cpp is generally only compatible with the master branch of Godot. Once we start doing -beta and -rc releases for 4.3, we'll make an issue that lists commits that are compatible with those version (for example, see https://github.com/godotengine/godot-cpp/issues/1267). Historically, we haven't done anything for compatibility with -dev releases, though.

Without a compatible engine version extensions built with this commit included no longer work, unfortunately.

It's true the other way too. If you have an extension_api.json from Godot built after PackedVector4Array was added, then godot-cpp from before this PR won't build anymore. So, for godot-cpp master to continue working with Godot master, we have to include this PR. Godot master is a moving target, and godot-cpp master needs to change to keep up.

Anyway, I guess if we wanted to start worrying about compatibility for -dev releases, we could keep track of commit hashes like we do for -beta and -rc releases?

YuriSizov commented 4 months ago

Godot master is a moving target, and godot-cpp master needs to change to keep up.

Yes, I understand that. But even so, in the engine repo one way changes like that are marked as breaking compat. Although I see that the label is not really used here. It would still be helpful to know when such changes occur.

Anyway, I guess if we wanted to start worrying about compatibility for -dev releases, we could keep track of commit hashes like we do for -beta and -rc releases?

My main point was having information. I have no idea if it's feasible or reasonable to worry about backwards compatibility with such changes. Right now you find out that the commit is incompatible by trying it and building it and trying to run it, which is more time consuming than checking for a label on recently merged PRs 🙃