A concrete policy for backward compatibility until Godot 5.0

### Problem or limitation When Godot maintainers want to or need to make changes that could break existing projects, there are currently few guidelines and frameworks to decide when and how. While we have [current policy](https://docs.godotengine.org/en/stable/about/release_policy.html#what-are-the-criteria-for-compatibility-across-engine-versions), it leaves some room for improvement, for example: - It defers important changes until 5.0, meaning the 4.x cycle sometimes continues to live with inferior engine designs. - It sets us up for a 4.0 situation where it becomes a free-for-all that erases our entire ecosystem. - It doesn't make enough assurances to Godot developers, risking problems when updating to new minor versions. - Godot contributors don't know if or when Godot 5.0 will happen, making "we can only do this in Godot 5.0" a practical "we will never do this". ### Proposed improvement > [!IMPORTANT] > This proposal was written by me, after consulting with maintainers and some Godot professionals. It is not an official policy yet (though I'm hoping it will get there) and is up for debate. Please use the comments to challenge it or add nuance. I propose the following adjustments to the [current policy](https://docs.godotengine.org/en/stable/about/release_policy.html#what-are-the-criteria-for-compatibility-across-engine-versions) (thanks to @dsnopek for some of these): - **We make changes as soon as feasible**, using compatibility systems (deprecation, migration to

Posted by Ivorforce on Jun 3, 2026, 4:13 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• New MTP models not supported