.readthedocs.yaml v2 Image and Interpreter Pinning When Older Tags Lack the Config File

Read the Docs reads .readthedocs.yaml from the checkout of the version being built, so a v2 config that pins build.os and the matching Python interpreter applies only to refs that actually contain that file. Release tags created before the config was added have none, so their builds resolve the image and interpreter from project-level defaults instead.

What those defaults are, and when they are evaluated, is the open question. A tag without the config may inherit the project's current web-UI build settings or the platform defaults in effect for that project, and either can differ from the default branch's pinned values. Version identity is a separate layer: the default branch, the newest tag mapped to stable, and the default version setting are independent decisions, and hidden versions still build without appearing in the version flyout.

Build logs report the config path, image and interpreter actually used, which is the practical way to compare versions. Image names, interpreter versions and plan boundaries change across platform releases, so any specific value needs confirmation.

• For a tag with no .readthedocs.yaml, does the build use the project's current web-UI build settings or the platform defaults for that project?
• Can an image or interpreter be pinned for a ref that cannot carry the config file, without rewriting the tag?
• When versions resolve to different interpreters, which one do the version warning banner and canonical URL settings assume?