as explored in #Zarr-Python > ✔ zarr-metadata docs, getting ReadTheDocs (RTD) to use the correct slug for subpackage docs pages like zarr-metadata.readthedocs.io/en/v0.4.0 is not obvious. RTD treats every git tag as a separate version, and it automatically assigns slugs to each version based on the tag. Conventionally, subpackages use a templated tag like zarr_metadata-v0.4.0 to encode the version string v0.4.0. RTD by default assigns the slug v0.4.0 to the commit tagged v0.4.0, which was an old zarr release, not a zarr-metadata release. Attempting to use the slug v0.4.0 for the zarr-metadata release tagged zarr_metadata-v0.4.0 will be blocked by RTD, as the v0.4.0 tag is claimed. The fix: select the v0.4.0 version in the RTD admin page for the subpackage docs and set its slug to something unused, like xv0.4.0. This releases the v0.4.0 slug, which can then be associated with the zarr_metadata-v0.4.0 tag.
we should explain this process in the release docs for subpackages.
as explored in #Zarr-Python > ✔ zarr-metadata docs, getting ReadTheDocs (RTD) to use the correct slug for subpackage docs pages like
zarr-metadata.readthedocs.io/en/v0.4.0is not obvious. RTD treats every git tag as a separate version, and it automatically assigns slugs to each version based on the tag. Conventionally, subpackages use a templated tag likezarr_metadata-v0.4.0to encode the version stringv0.4.0. RTD by default assigns the slugv0.4.0to the commit taggedv0.4.0, which was an oldzarrrelease, not a zarr-metadata release. Attempting to use the slugv0.4.0for the zarr-metadata release taggedzarr_metadata-v0.4.0will be blocked by RTD, as thev0.4.0tag is claimed. The fix: select thev0.4.0version in the RTD admin page for the subpackage docs and set its slug to something unused, likexv0.4.0. This releases thev0.4.0slug, which can then be associated with thezarr_metadata-v0.4.0tag.we should explain this process in the release docs for subpackages.