Make Version Checks More Robust For Godot Engine Forks/Derivatives

[TheNichKing]

Hello,

Currently Godot performs many version checks throughout the engines for various features such as GDExtensions and UID feature sets. However, in it's current implementation the checks are strongly tied with Godot's version naming schema (v.4.3, 4.4.1, etc). As it stands, any forks of Godot that choose to do their own versioning system (for example starting with version 1.0 for their own named software) would conflict with these checks.

In particular, this makes trying to recompile GDExtensions to target those forks with different version naming schemas a bit of a nightmare as anything below 4.0 or 4.1 are simply not accepted even if the fork was derived from Godot v.4.3 for instance. While this may be an overstatement, I feel this conflicts somewhat with the open-source driven mission of Godot as even though the game engine supports dumping of json and header files for GDExtension recompilation, the version numbering causes a conflict even though it should be supported fine. This is a particular issue if a fork wants to take advantage of the MIT license to form a closed source fork of Godot that otherwise should have no problem accepting recompiled GDExtensions targeting that fork. While a solution would be to change all the version checks to match the new numbering system, this seems somewhat messy and not very future facing of a solution especially in regards to updating to newer versions of Godot as more features are added with these checks.

I think it would be beneficial to consider methods to making the version checks more robust. For instance, I think what some Linux distributions do is have the "forked" name of the distribution (e.g. Zorin ver 17) and the "inherited" name of the original distribution (e.g. Ubuntu 22.04 LTS) stored at the same time and software can check the inherited version for compatibility.

[AThousandShips]

I'd say if people want to use their own versioning they should change the relevant code, I don't think it makes sense to make our engine adjust to how others choose to change the engine separately

Open source means anyone can fork and change the engine, which includes if they want to adjust the versioning, but it doesn't mean we should bloat the engine for hypothetical scenarios IMO

If it's not a lot of work to change it then forks can just do it themselves, but if it's a lot of work then it's really not justified to spend resources on it

[theraot]

I do not expect a GDExtension that works for Godot to work for a fork, because I do not know what they changed. If I were releasing such GDExtensions, I'd have to test on them, and if version checks are an issue, then I'd also have to release for them.

It seems - for what you say - that the changes to support these forks are minimal. That is, at the moment it seems forks are mostly doing cosmetic changes and adding stuff, and not introducing many breaking changes. But I don't think we can rely on that. Some Forks might choose to go in a very different way, and providing cross compatible plugins might not remain viable.

Thus, we can to restrict the discussion to forks that wish to remain compatible. In that case, I see thee solutions:

1. They can add a way to bypass the checks under user consent.
2. They can change the way the check is done by adding a way for the GDExtensions to indicate if they are for them, which if missing they assume the GDExtension is for Godot, and check the version accordingly.
3. They can keep Godot versioning.

I'll elaborate on the last point: I'm not saying you can't have your 1.0. If you don't think of it as the version of Godot, but as the version of the API and one of the goals of your project is keep compatibility with the API, then it makes sense to keep the same version numbers, even if those are not the version numbers you show to end user (or package system if any).

Did you know that Java 5 is actually Java 1.5? The version number you show to the end user, the version number for marketing and public relations, and the version number used internally for checks... They do not have to agree.

Of course, forks that do not wish to maintain compatibility do not have to care about this. And you should not expect GDExtensions for Godot to work on them, unless the author of said GDExtensions has taken steps to make a version for the fork available.