Release metadata
sphinxpress can attach release tags and release URLs to generated navigation
data.
Release metadata and source selection are related but separate:
release metadata answers “what release label and URL should this target show?”
source selection answers “which checkout should Sphinx actually build?”
For versioned site builds, the release variant resolves a release tag and
materializes that exact Git object before running Sphinx. A git_ref variant
resolves an explicit branch, remote ref, or commit SHA and materializes that
commit separately.
Supported project strategies are:
manual, using the project’s configuredrelease_taggit_tag, resolving the latest matching git tagpyproject, reading package metadata frompyproject.toml
The release URL is formatted with [release].release_url_template:
[release]
tag_prefix = "v"
release_url_template = "{repo_url}/releases/tag/{tag}"
Use update-release to set one manual tag and update-releases to refresh all resolvable tags.
For git_ref variants, the source URL is formatted with
[release].branch_url_template:
[release]
branch_url_template = "{repo_url}/tree/{ref}"
Versioned builds do not fetch refs or tags automatically. If a configured
release tag or git_ref is missing locally, sphinxpress raises an actionable
error instead of falling back to the current working tree.
The git_tag strategy still uses git describe --tags --abbrev=0, so
“latest release” means the nearest reachable tag from the checked-out history,
not a separate semantic-version sort across all tags.