release.sh derives a tag name that GitHub permanently refuses

[vishr]

What happened

All releases and tags were deleted from this repository on 2026-08-24. scripts/release.sh derives the next tag by listing existing v<year>.<month>.* tags and incrementing the highest one, falling back to .0 when it finds none:

last=$(git tag --list "${series}.*" --sort=-v:refname | grep -E "^${series}\.[0-9]+$" | head -1 || true)
if [ -z "$last" ]; then
  number=0

With no tags present it therefore computes v2026.8.0. That name cannot be created: GitHub's immutable releases permanently reserve a tag name once a release has been published under it, and the reservation survives deleting both the release and the tag. Recreating the ref fails with 422 Reference update failed.

v2026.8.0 through v2026.8.9 are all burned for this repository. v2026.8.10 was tagged by hand to restart the series, so the script works again for now — but the fallback is still wrong, and the next repository-wide tag reset, or the first release of any future month whose numbers were previously used, hits the same wall.

Suggested fix

Have the script treat a 422 on the tag push as "this name is reserved" and retry with the next number, rather than failing. A cheaper variant: when no tags exist locally, ask the API for the highest tag name the repository has ever published rather than assuming .0 is free.

Also worth knowing

The container images published to ghcr.io/labstack/fanout and docker.io/labstack/fanout under the deleted version tags still exist, and their org.opencontainers.image.revision labels point at commits that are no longer reachable. :latest was refreshed by the v2026.8.10 release. Pruning the stale version tags from both registries is a separate cleanup.