Skip to content

Docs: the landing version falls back to a fixed release, 0.5.2, not the latest - #76

Open
jonathan-taylor wants to merge 1 commit into
mainfrom
docs-landing-default
Open

jonathan-taylor wants to merge 1 commit into
mainfrom
docs-landing-default

Conversation

@jonathan-taylor

Copy link
Copy Markdown
Collaborator

The site's root redirects to the version in landing.txt on gh-pages. When that file was missing, for example after gh-pages was rebuilt from scratch, the workflow fell back to the latest release. After 0.7.0 that would quietly send readers to 0.7.0, but the root should stay on 0.5.2.

The deploy job now has a fixed DEFAULT_LANDING: '0.5.2', which is bumped by hand:

  • -f landing=X.Y.Z still sets the landing version, and is kept in landing.txt.
  • An existing landing.txt is still kept. Today it holds 0.5.2.
  • With no landing.txt, the workflow uses DEFAULT_LANDING and writes it to landing.txt.
  • If that version has no folder on gh-pages, the run stops with the existing error instead of landing elsewhere.

I tested the deploy script against a mock gh-pages with 0.5.2/, 0.6.0/, 0.7.0/ and dev/:

Case Root goes to
no landing.txt 0.5.2 (and landing.txt is written)
landing.txt = 0.6.0 0.6.0
-f landing=0.7.0 0.7.0

The YAML parses. The header comment, the input's description and the changelog entry now describe the new fallback.

🤖 Generated with Claude Code

…he latest

With no landing.txt on gh-pages (e.g. the branch remade), the site's root
went to the latest release. It now goes to DEFAULT_LANDING, set in the
workflow to 0.5.2 and bumped by hand, and landing.txt keeps it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant