Godot ships two stable lines at once, and the export templates are a second download

The editor and the export templates are two downloads, and the export is the one that fails

Read the getting-the-engine section as a list of two artefacts rather than one.

Official binaries for the Godot editor and the export templates are on the project website. Two things, described together, and they are installed by different means.

That distinction is the whole reason a one-click export sometimes is not a one-click anything. The editor runs without templates. The export path needs a template matching the exact editor build, placed where the editor looks for it, and until that file exists the export is a failure at the end of a chain of steps that otherwise work. A newcomer downloads the editor, builds a project, presses export, and lands on an error whose message points at packaging rather than at the missing download.

The README does not walk through template installation, and it does not need to, because this is documented elsewhere. What it does is name both artefacts in one sentence, which is the signal to look for both. The practical habit is to fetch the template bundle for your version at the same time as the editor, and to re-fetch it after every editor update, since the pairing is by build and not by major version.

3.6.3-stable is newer than 4.7.2-stable, so sorting releases by date picks the wrong major

Read the three most recent stable releases in order.

3.6.3-stable, published 2026-08-22. 4.7.2-stable, published 2026-08-18. 4.7.1-stable, published 2026-07-14.

The oldest-numbered release is the most recent one. Two consequences follow, and both are the kind of thing that only shows up after you have committed to a version.

The first is mechanical. Any tooling that takes the newest release as the current version, which is what a great many release watchers, container tags and update scripts do, resolves to 3.6.3. You get the previous major line, silently, with a version string that looks current. The tag naming makes it worse rather than better, because the three tags are all labelled stable and there is nothing in the name that distinguishes a maintained older branch from the current one.

The second is that this is a maintenance signal rather than an accident. The 3.x line is still receiving point releases while 4.7 is on its second point release, which means a project started on 3.x has somewhere to go without a major migration. For a studio with an existing 3.x project, that is a reason to stay put, and it is also a reason to name your major line explicitly in any dependency or container specification, because the tag alone will not do it for you.

The online docs are a separate repository tracked as latest, so they can describe an API you do not have

The documentation is hosted on Read the Docs and maintained by the community in its own GitHub repository, which is not this repository. That split has a consequence that anyone following a tutorial hits eventually.

The hosted documentation is versioned as latest, meaning it tracks the current state of the docs rather than the state of your binary. So a page you are reading can describe a property, a method or a whole class that does not exist in the version you have installed, and the failure surfaces as an error in the editor or at runtime rather than as a helpful message.

The mitigation is in the same paragraph, and it is worth knowing about. The class reference is also accessible from within the Godot editor. That copy is generated from the engine you are running, so it always matches. A reader who has both has a way to check: when the online page and the in-editor reference disagree, the in-editor one is right for that build.

This is why the in-editor reference is a better habit than the website for anything version-sensitive, and why the demos repository and the asset store are worth more than tutorials written against a different version.

The build is SCons with custom builders, and those Python builders are linted and typed

The top level of the repository is a C++ tree, and it is also a Python project, and the second fact is unusual enough to be worth spelling out.

The build entry point is an SConstruct file, with per-directory SCsub files, and there are four custom builder scripts at the root: gles3_builders.py for the shader language, glsl_builders.py, scu_builders.py, and two shared helper modules, methods.py and platform_methods.py.

Those Python files are not treated as throwaway scripts. pyproject.toml configures mypy for them with warn_return_any, warn_unreachable, no_implicit_optional and disallow_any_generics all enabled, and it configures ruff with isort and pyupgrade rule sets, a line length of 120, and extend-include entries that pull SConstruct and SCsub themselves into linting. The isort configuration adds a custom section called metadata, populated from a module named misc.utility.scons_hints, so build files can carry hints in a dedicated import block.

The result is that a build system for a C++ engine is held to the same static analysis standard as application code, which is a real quality signal for anyone who is about to patch the build. It also means a change to a builder has to satisfy type checking before it can be tested.

The ruff rule set is deliberately held on the legacy defaults

One comment in the lint configuration is the clearest statement of engineering policy in this repository, and it is about resisting upgrades.

It records that starting with ruff 0.15.2 the tool uses a significantly expanded set of default rules for preview builds, that expanding into the new rule sets is something the project is interested in, that they will be adopted gradually depending on needs, and that the base select therefore utilises the legacy defaults. The current base select is E4, E7, E9 and F, with FA, I and UP added on top and one rule explicitly ignored.

So a dependency bump does not silently change what fails your build. That is a deliberate, documented choice, and it is the right one for a project with a large contributor base, because a linter upgrade that adds a hundred new violations is a way to lose people.

It has a cost worth naming. New rules stay off until somebody decides to turn them on, so the codebase accumulates style debt in the categories nobody has adopted yet, and a contributor bringing an upstream habit gets no signal that it is unwanted. The per-file-ignores for SConstruct and SCsub show the same pragmatism: those two files are exempted from module-level-import-ordering and from star-import checks, which is what you would expect for generated or generated-adjacent build glue.

thirdparty/ is excluded from type checking and linting, and it is a top-level directory

Both analysis tools in pyproject.toml name the same directory to leave alone.

mypy sets exclude to thirdparty/ and ruff sets extend-exclude to thirdparty, while ruff's codespell configuration runs with check-hidden enabled and skips a specific list of files that includes core/input/gamecontrollerdb.txt, core/string/locales.h and editor/project_converter_3_to..., among others.

The exclusion is correct practice. Vendored third-party code should not be reformatted or type-checked against your own settings, and a project that did otherwise would generate a permanent wall of failures nobody could fix upstream. The consequence is a boundary inside the repository that the tooling will not police.

That boundary is the thing to look at, because thirdparty/ sits at the top level next to core/, editor/ and servers/ with no marker other than the name. A licence inventory or a security review has to walk it deliberately, since no lint run will report anything about it. The same applies to the codespell skip list: those files are excluded from spelling checks because they contain data, generated text or third-party content, which is the right call and also a list of places where a typo will never be caught.

MIT covers the current engine, and the pre-2014 history was work-for-hire

The licence claim is emphatic. Godot is free and open source under a very permissive MIT licence, no strings attached and no royalties, and the users' games are theirs down to the last line of engine code. It is supported by the Godot Foundation, a not-for-profit.

The history sentence sits right below it and is the one that matters in a review. Before being open sourced in February 2014, Godot had been developed for several years as an in-house engine, used to publish several work-for-hire titles.

A work-for-hire engagement is a commercial arrangement, and the open sourcing in 2014 is a change in how the project is funded rather than a change in who wrote it. So there are two eras of code with two different provenance stories, and the MIT file at the root speaks plainly about one of them.

This is not a reason to avoid the engine, and it is not a legal opinion either. It is the reason a careful reviewer reads COPYRIGHT.txt and LICENSE.txt as two separate files at the top level, alongside AUTHORS.md and DONORS.md, rather than treating the licence file as the whole answer on authorship. Anyone vendoring a fork into a commercial product should have their own counsel look at what a 2014 open sourcing event does and does not cover.

Editorial conclusion

Use Godot when you want a permissive licence with no royalties, a single interface covering 2D and 3D, and an export path to desktop, mobile, web and console targets from one project. Do not pick your version by sorting releases by date, because the 3.x line is still receiving stable releases and 3.6.3-stable is four days newer than 4.7.2-stable, so you need to decide which major line you are on before you pin anything. Two things to verify first: that you have installed the export templates matching your editor build, because the one-click export does not work without them, and that your documentation matches your binary, because the docs are a separate repository versioned as latest while the class reference inside the editor is the copy that agrees with what you have.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes