[stable33] fix: show numbered version in manual titles and version picker - #15155
Merged
Conversation
Replace the bare "latest" label with the actual Nextcloud version number (derived from version_stable + 1) across all three manuals. - Add display_version = str(version_stable + 1) in conf.py, auto-updating when version_stable increments at each release - Use display_version in project names, html_title, and |version| RST substitution so titles read "Nextcloud 34 User Manual" instead of "Nextcloud latest User Manual" - Update generateVersionsDocs to return (slug, url, label) 3-tuples so the version picker shows "33 (stable)" and "34 (latest)" rather than bare "stable" / "latest" slugs - Update all three versions.html templates to render the label and expose display_version for the collapsed picker button Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
Add a validation step in the build-html job that detects the highest and lowest stableNN branches via git ls-remote and fails if either drifts from the hardcoded constants in conf.py. Local builds are unaffected — the hardcoded values remain the fallback. Update conf.py comments to explain the CI validation and the conditions under which each constant must change. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
Old/stable branches have historically correct conf.py snapshots from their era; validating against current remote branches would always fail. Restrict the check to master and PRs targeting master where keeping version_stable and version_start current actually matters. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
git ls-remote alone would pick up a stableNN branch that exists but hasn't had vN.0.0 released yet (RC phase). Mirror the same curl + GitHub API release check used in the stage-and-check job and build-index.php to find the true highest released stable. version_start (lowest documented) still uses ls-remote — branch existence is the right signal there. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
Instead of hardcoding "latest" as DOCS_RELEASE for master branch PDF builds, compute version_stable + 1 from conf.py so the PDF cover page shows the actual development version number (35) rather than "latest". Stable branch builds are unaffected. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
fix: exclude version_stable from numbered range in version picker version_stable is already shown as "N (stable)" — including it in the plain numbered range caused it to appear twice in the picker. Signed-off-by: skjnldsv <skjnldsv@protonmail.com> [skip ci]
The cherry-pick missed the display_version definition entirely, causing a NameError on any build. Add it with GITHUB_REF-based stable branch detection so HTML builds show the correct version number. Update version_stable from 32 to 34 (current highest released stable) and version_start from 31 to 32 (oldest documented) so the version picker reflects the current state of all branches. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
4 tasks
skjnldsv
marked this pull request as ready for review
June 16, 2026 07:26
Contributor
📖 Documentation PreviewNo RST documentation pages changed in this PR. Last updated: Tue, 16 Jun 2026 08:12:46 GMT |
…and PDF The previous approach matched GITHUB_REF against stable branch patterns, which broke for backport/*/stableNN branches where GITHUB_REF is the source branch, not the target. Use GITHUB_BASE_REF (the PR target branch, always stableNN) for PRs, falling back to GITHUB_REF for direct pushes. Both are matched strictly against ^stable([0-9]+)$ — no loose suffix matching. Also set html_context current_version to the detected stable version integer so the picker correctly highlights the current docs version instead of always showing "latest" as selected. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
4 tasks
Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
display_version reflects the current branch (e.g. '32' on stable32), which is correct for titles and the picker button but wrong for the 'latest' picker entry which should always show the master dev version. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
… docs When building docs for a branch older than version_start (e.g. stable26), the picker now includes that version labeled "(unsupported)" at the bottom, so users can see: 35 (latest), 34 (stable), 33, 32, 26 (unsupported). Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
skjnldsv
approved these changes
Jun 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #15140 to stable33.
Additional fixes applied on top of the cherry-pick:
display_versiondefinition entirely (NameError on every build) — added withGITHUB_REF-based stable branch detection so HTML builds show "33"version_stableupdated from 32 to 34 (current highest released stable) so the version picker reflects the current stateversion_startupdated from 31 to 32 (oldest documented branch)✅ Checklist