Which Godot Version Should I Use for a New Project?
For a new project, start with the latest stable release of Godot. The official documentation is published for the current stable branch (shown as the 4.7 branch in the source), and that branch is the reference point for features, fixes, and platform support. Choose an older version only when a specific plugin, asset, or export target requires it.
Why the latest stable branch is the default choice
The documentation site you are reading is versioned by branch, and the stable branch is the one maintained as the current release line. New projects benefit from:
- Current platform support — the stable branch documents the platforms and system requirements that are actively maintained.
- Bug fixes and security updates — fixes land on the stable branch first.
- Accurate documentation — tutorials, class references, and feature pages match the stable branch, so what you read applies to what you run.
- Plugin and asset compatibility — most actively maintained addons target the current stable release.
The docs list a dedicated FAQ entry, "Which Godot version should I use for a new project?", alongside "Should I upgrade my project to use new Godot versions?" — both point to the same practical rule: new work goes on stable, upgrades are a separate decision.
When to pick something other than the latest stable
| Situation | Reasonable choice |
|---|---|
| A required plugin or asset only supports an older branch | Use the oldest version that plugin supports, and check whether a newer release of the plugin exists |
| You need a feature only present in a development build | Use the development build for prototyping, but expect breaking changes before it reaches stable |
| You are maintaining an existing project | Stay on its current version unless you have a reason to upgrade |
| You need long-term reproducibility for a shipped title | Pin the exact version and keep it recorded with the project |
The documentation does not promise that development builds are stable, and it does not list a fixed support window for older branches. Treat any non-stable version as a temporary choice.
Checking compatibility before you commit
Before starting, verify three things against the branch you plan to use:
- Plugins and assets — open the addon's repository or store page and confirm which Godot versions it declares. A plugin that has not been updated for the current stable branch may still work, but you are taking on the maintenance risk.
- Export targets — check the platform you intend to ship to. The docs cover supported platforms and system requirements for both the editor and exported projects; confirm your target appears there.
- Renderer choice — the FAQ includes "Should I use the Forward+, Mobile, or Compatibility renderer?" This affects which devices your project can run on, so decide it early rather than migrating later.
Upgrade path considerations
If you start on the latest stable branch, future upgrades are the normal, documented path. If you start on an older branch, you are choosing to do that upgrade work later, possibly across multiple versions.
- Upgrading is a project decision, not an automatic one. The docs treat "Should I upgrade my project to use new Godot versions?" as a question with trade-offs, not a yes/no rule.
- Upgrade when you need something the new version provides — a platform, a feature, or a fix — and when your plugins and assets support it.
- Test before committing. Keep the old version available so you can compare behavior if something breaks.
- Read the release notes for the versions you skip, not just the one you land on, since changes accumulate.
A practical starting checklist
- Install the latest stable release from the official download page.
- Confirm your target platform is listed in the supported platforms and system requirements sections.
- Pick your renderer based on your target devices, using the FAQ entry as a guide.
- Check every plugin and asset you plan to use for its declared Godot version.
- Record the exact version in your project notes so collaborators and future-you can reproduce the setup.
- Only move to a development build if you specifically need an unreleased feature, and plan to move back to stable.
The short version: latest stable for new projects, older versions only for a concrete compatibility reason, and treat upgrades as planned work rather than something that happens by accident.