Godot: Compatibility goals for 3.1

[RandomShaper]

For 3.0 we were able to add/remove/modify APIs freely since we took the chance to break compatibility with 2.1.

What's the exact design philosophy for 3.1 regarding this?

• Are projects created with 3.0 expected to be openable with 3.1 although they may not run due to missing APIs, etc.?
  In that case we need a different value for config_version in project..godot.
• Can we safely (re)move project/editor settings between those releases?
  If that's the case, I think editor_settings-3.tres can no longer be shared because on the editor settings dialog for 3.0 you may see settings that didn't exist yet and on 3.1 you may see settings that were already removed.

I guess more questions like these can be asked.

[bojidar-bg]

Here is my understanding of semver:

v should be able to read > | 2.1.x | 3.0.x | 3.1.x
----------: | --- | --- | ---
2.1.y | Yes | No | No
3.0.y | No | Yes | No
3.1.y | No | Yes | Yes

So:

• Different major version: no support.
• Different minor version: forward-compatible (old is compatible with new).
• Different patch version: forward and backward-compatible (mainly bugfixes).

[lopho]

Different minor version: forward-compatible (old is compatible with new).

Just a small correction here: forward compatible implies that an application can handle data from later versions, e.g. 3.0.x running 3.1.x projects. What you actually refer to is backward compatibility, newer versions handling data from previous versions, e.g. 3.1.x running 3.0.x projects.

Sidenote: Partial forward compatibility is not excluded though. For example a C-API. If an API update does not change the symbols in the ABI and only extends with new symbols that don't interfer with the old ones, it is possible to interface on a binary level from a previous version to a later one. But that is not in the scope of semantic versioning.

Are projects created with 3.0 expected to be openable with 3.1 although they may not run due to missing APIs, etc.?

If SemVer is really a target for versioning in Godot, a deprecation mechanism would be something to strive for, if not already in place. Deprecating on minor/patch, removing on major version changes.

https://semver.org/

[akien-mga]

Are projects created with 3.0 expected to be openable with 3.1 although they may not run due to missing APIs, etc.?
In that case we need a different value for config_version in project..godot.

We do have a different value now, since there were incompatible changes in the input format. It does prevent opening 3.1 projects in 3.0, and 3.1 will show a warning before opening and converting 3.0 projects.

Can we safely (re)move project/editor settings between those releases?
If that's the case, I think editor_settings-3.tres can no longer be shared because on the editor settings dialog for 3.0 you may see settings that didn't exist yet and on 3.1 you may see settings that were already removed.

IMO the current status quo is fine. We do rename or remove some project/editor settings every now and then, but nothing that would cause huge confusion. Only settings that were actually used with a custom value could be problematic if they're silently dropped/renamed, but even then it's not really a big enough deal to warrant fully splitting the editor settings IMO.

I go between 3.0 and 3.1 projects all the time (thus reusing editor settings) and I never have any problem.