[GDNative] refactored API struct into core and extensions

[karroffel]

No description provided.

[akien-mga]

The comma is still needed here, no?

[karroffel]

Oh yeah, for some reason it's not an error so I didn't notice. Will fix.

[akien-mga]

Missing comma?

[endragor]

Is there a point in having three-number version for APIs instead of just one number? How do you plan to version the APIs, i.e. what would semantically a change of each number mean?

[endragor]

Also it probably makes sense to extract fields type and next into a separate struct (godot_gdnative_api_header). Because, if I'm not mistaken, those two first fields in specific API structs may be aligned differently between different structs, so you may not be able to check the type properly.

[endragor]

We also discussed that binding libraries should have a way to report an error about unknown version (or API type in this case). Could you please add that?

[karroffel]

Is there a point in having three-number version for APIs instead of just one number? How do you plan to version the APIs, i.e. what would semantically a change of each number mean?

Two numbers should be enough, yeah. It should be using semantic versioning. If we add more functions to the core or extensions then the patch minor version would be bumped. Major would be bumped if compatibility gets broken. So 3.0.1 might have a core version 1.1 while Godot 4.0 will probably have 2.0 again.

Because, if I'm not mistaken, those two first fields in specific API structs may be aligned differently between different structs, so you may not be able to check the type properly.

No, those fields should be the same since the struct are not annotated to be packed, so all compatible C compilers will align the fields all in the same places.

We also discussed that binding libraries should have a way to report an error about unknown version (or API type in this case). Could you please add that?

Yes, will add that, thanks for reminding me!