Skip to content

[stable32] fix: show numbered version in manual titles and version picker - #15156

Merged
skjnldsv merged 11 commits into
stable32from
backport/15140/stable32
Jun 16, 2026
Merged

[stable32] fix: show numbered version in manual titles and version picker#15156
skjnldsv merged 11 commits into
stable32from
backport/15140/stable32

Conversation

@backportbot

@backportbot backportbot Bot commented Jun 16, 2026

Copy link
Copy Markdown

Backport of #15140 to stable32.

Additional fixes applied on top of the cherry-pick:

  • The cherry-pick missed the display_version definition entirely (NameError on every build) — added with GITHUB_REF-based stable branch detection so HTML builds show "32"
  • version_stable updated from 32 to 34 (current highest released stable) so the version picker reflects the current state
  • version_start updated from 31 to 32 (oldest documented branch)

✅ Checklist

  • Review and resolve any conflicts
  • Review and verify the backported changes

skjnldsv added 6 commits June 16, 2026 07:16
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>
@skjnldsv
skjnldsv marked this pull request as ready for review June 16, 2026 07:26
@github-actions

github-actions Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

📖 Documentation Preview

🔍 Open preview →

No RST documentation pages changed in this PR.

Last updated: Tue, 16 Jun 2026 08:13:01 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>
skjnldsv added 3 commits June 16, 2026 09:40
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
skjnldsv merged commit f4d7a7a into stable32 Jun 16, 2026
21 checks passed
@skjnldsv
skjnldsv deleted the backport/15140/stable32 branch June 16, 2026 08:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant