fix(index): use the updater EOL dates for supported versions

[skjnldsv]

The index on docs.nextcloud.com listed 32 as supported and labelled both 33 and 32 "This documents the last supported stable version of Nextcloud", visible on the page deployed by #15631.

detect_versions() took the release date from the vN.0.0 release tag and added 365 days. That disagrees with the end of life dates the updater serves in major_versions.json:

"35": { "minPHP": "8.3" },
"34": { "eol": "2027-06-09", "minPHP": "8.2" },
"33": { "eol": "2027-02-18", "minPHP": "8.2" },
"32": { "eol": "2026-09-10", "minPHP": "8.1" },

32 reached end of life on 2026-09-10, the builder put it at 2026-09-27, so the index kept it in the maintained list for a week. The release tag is the wrong input twice over: published_at for v35.0.0 is 2026-09-15T21:40:40Z while the announced date is a day later, and 365 days is not 12 calendar months once a window spans a leap February.

So detect-versions.php reads major_versions.json instead: maintained is an entry with no eol yet, or one whose eol has not passed. That is the same source MajorLifecycle in nextcloud-releases/server derives maintenance from, so the index cannot disagree with the updater about what is supported. It also drops one GitHub API call per version and the rate limit abort path that came with them, since the file is a single unauthenticated fetch.

The duplicated label was separate. The section role came from the loop index, which generate_section() only defines for 0 to 3:

$index = ($idx + 1 === count($stableVersions) && count($stableVersions) > 1) ? 3 : $idx + 1;

With four entries, index 2 got $idx + 1 = 3 and index 3 got 3 from the last-element rule, so both rendered the same sentence. Only the newest and the oldest maintained version carry a note now, and the ones between them carry none, so the labels stay correct for any number of maintained majors. Twelve months of support over a four month cadence gives three today, but a change of cadence should not need a change here.

conf.py version_start goes 32 → 33 because build-docs.yml fails the master build when that fallback disagrees with lowest_stable.

server/32 stops being rebuilt. The deploy step only adds version folders and never prunes, so the existing tree stays and the legacy block keeps linking it, PDFs and ePubs included.

☑️ Resolves

No issue filed, spotted on the deployed page from #15631.

🖼️ Screenshots

✅ Checklist

• I have built the documentation locally and reviewed the output
• Screenshots are included for visual changes
• I have not moved or renamed pages (or added a redirect if I did)
• I have run codespell or similar and addressed any spelling issues

Regenerating the index against live data and diffing against the deployed one, the only changes are 32 moving into the legacy block and 34 losing its note:

$ php build/build-index.php 35 34 33 32 … 12
✅ Version 35 is maintained (no end of life announced)
✅ Version 34 is maintained (end of life on 2027-06-09)
✅ Version 33 is maintained (end of life on 2027-02-18)
🛑 Version 32 reached end of life on 2026-09-10
$ php build/verify-index.php
✓ Maintained version notes are unambiguous

Both assertions were checked against a deliberately broken index (note "latest stable" appears 2 times, no version is labelled as the latest stable), and the role assignment against 1, 2, 3, 4 and 5 maintained versions. The Sphinx manuals were not rebuilt, so the conf.py version picker change is reasoned about rather than observed: range(33, 35) yields 33 and 34, plus stable 35 and latest 36.

👾 This pull request was assisted by Claude Code, commits carry an Assisted-by trailer.

[github-actions]

📖 Documentation Preview

🔍 Open preview →

No RST documentation pages changed in this PR.

Last updated: Fri, 18 Sep 2026 07:53:21 GMT

[AndyScherzinger]

🐘