Skip to content

chore: drop the 10.15 server documentation version - #144

Open
oc-tmueller wants to merge 3 commits into
mainfrom
chore/drop-server-10-15
Open

oc-tmueller wants to merge 3 commits into
mainfrom
chore/drop-server-10-15

Conversation

@oc-tmueller

Copy link
Copy Markdown
Contributor

Why

11.0 is latest and 10.16 is previous, so 10.15 is two lines out of support. Its tree is 1002 files / 55 MB that nothing in the current documentation links to, and it costs a config-docs-in-sync leg on every PR and every nightly run — cloning core's 10.15 branch to verify pages nobody reads.

What

Follows the "Dropping a version" procedure in README.md.

  • content/server/10.15/ deleted. site.yml needs no edit because it globs content/server/*, and deletion is the only way to unpublish a server version: keeping the folder unlisted (the shape used for content/ocis/7.3 and 8.0) would not help, because config-docs-in-sync.yml iterates content/server/*/ independently of site.yml and would keep checking it.
  • PUBLISHED_VERSIONS in ui/supplemental/js/go-redirect.js and the version loop in extension-tests/go-redirect.test.js — two independent hand-maintained lists. Verified in both directions by reverting one change at a time: PUBLISHED_VERSIONS matches the built server version segments catches the first, a published version segment is preserved for per-version fidelity the second.
  • sync/manifest.yml row and the README "Versions imported" table.
  • global-attributes.yml is untouched — 10.15 appeared in none of the latest-*/previous-*/current-* attributes, and the latest/next alias trees derive their targets automatically.

The historical == Changes in 10.15.x sections in server_release_notes.adoc stay. That page is an archive reaching back to 10.0.7 and is not tied to which versions are published.

Accepted cost

Per step 4 of the procedure the README documents: nothing redirects a retired version tree, so inbound https://doc.owncloud.com/server/10.15/... links now reach the site 404 page. Legacy go.php?to= links are covered — they fall through to /server/latest/ — but hardcoded non-go.php deep links from an older core are not.

README corrections found by following its own procedure

Two commits of follow-up, because the documented procedure turned out to be wrong about itself in ways a reader would act on:

  • It named test/go-redirect.test.js and test/static-files.test.js; both moved to extension-tests/ in test: repair the extension-tests suite broken by the test/ rename #135. The last stale reference lived in ui/supplemental/ui.yml.
  • It did not mention the second hand-maintained list, the sync/manifest.yml row, or its own table. All are bookkeeping steps now. It also now states the asymmetry: a removal missing either list fails the suite, but an addition missing the loop fails nothing, so a new server line would silently never be exercised.
  • The release-rollover note claimed static-files.test.js fails while any of three things disagree. It cross-checks latest-*-version only — LATEST_ATTRIBUTE_BY_COMPONENT lists five keys and nothing else — so previous-*-version, current-server-version and latest-server-download-version are verified by no test and a stale one renders site-wide on a green build. (previous-android-version already equals latest-android-version, which is what that looks like when it happens.)
  • The rm -r example no longer names a concrete version. It is the one command in these docs meant to be pasted, and naming a live version meant pasting it deleted a supported tree. VERSION is a valid path component rather than <version>, which is a bash syntax error inside a sh block.

Verification

npm run antora && npm test
  • public/server/ publishes exactly 10.16, 11.0, latest, next.
  • 51 pass, 1 skip, 0 fail. The skip is pre-existing (a page missing from the prerelease line redirects to the latest release — no page is published in a release but absent from its prerelease line).
  • robots.txt and llms.txt still publish at the site root, confirming the ui.yml comment edit did not disturb the descriptor.
  • config-docs-in-sync goes from 3 versions / 6 pages to 2 / 4. 10.15's pages were brought in sync by docs: sync config.sample.php parameters for 10.15 #142, so this removes a passing leg, not a failing one.

🤖 Generated with Claude Code

@oc-tmueller

oc-tmueller commented Sep 25, 2026 •

Copy link
Copy Markdown
Contributor Author

config-docs-in-sync is red for a pre-existing reason, not because of this PR

The three required checks (license/cla, lint, build) are green. config-docs-in-sync is not a required context on main — the required list is exactly license/cla, lint, build — so this does not gate the merge.

The drift it reports is in 10.16 and 11.0, not 10.15: core's config/config.apps.sample.php gained the openidconnect audience key, and the committed config_apps_sample_php_parameters.adoc pages have not been regenerated. #137 (docs: document the OIDC audience parameter, still a draft) carries both regenerated pages and is the PR that closes this.

It has been failing on main nightly since 2026-09-22 — schedule runs on 09-22, 09-23, 09-24 and 09-25 all red — so it predates both of my branches. This is the documented cost of that workflow being deliberately un-path-filtered: drift introduced by a core commit surfaces on whichever docs PR opens next.

Correcting my own PR description: it says this change "removes a passing leg, not a failing one". That was true of the 10.15 leg specifically (#142 brought those pages in sync, and 10.15 does not appear in the drift), but it wrongly implies the job as a whole was green before. It was not.

oc-tmueller and others added 3 commits September 25, 2026 17:03
11.0 is `latest` and 10.16 is `previous`, so 10.15 is two lines out of
support and its tree is 1002 files / 55 MB that nothing links to from the
current documentation. It also costs a `config-docs-in-sync` leg on every
PR and every nightly run, cloning core's 10.15 branch to verify pages
nobody reads.

This follows the "Dropping a version" procedure in README.md. `site.yml`
needs no edit because it globs `content/server/*`; deletion is the only
way to unpublish a server version. Keeping the folder unlisted - the
shape used for ocis 7.3 and 8.0 - would not work here anyway, because
config-docs-in-sync iterates `content/server/*/` independently of
site.yml and would keep checking it.

`PUBLISHED_VERSIONS` in go-redirect.js and the version loop in
go-redirect.test.js are two independent hand-maintained lists, and the
suite fails on either one alone. Verified in both directions by reverting
one change at a time: `PUBLISHED_VERSIONS matches the built server version
segments` catches the first, `a published version segment is preserved for
per-version fidelity` the second. Legacy `go.php?to=` links under
/server/10.15/ now fall back to /server/latest/, which is what that list
exists to do.

The `latest` and `next` alias trees move on their own, and 10.15 appeared
in none of the `latest-*`/`previous-*`/`current-*` attributes, so
global-attributes.yml is untouched. `npm run antora && npm test` publishes
exactly 10.16, 11.0, latest and next under public/server/, 51 pass 0 fail.

The historical `== Changes in 10.15.x` sections in server_release_notes.adoc
stay - that page is an archive reaching back to 10.0.7 and is not tied to
which versions are published.

Two things README.md got wrong about its own procedure, found by following
it: it named `test/go-redirect.test.js`, which moved to `extension-tests/`
in #135 and holds a second list it did not mention, and it did not mention
the `sync/manifest.yml` row or the table in the README itself. Both are
now bookkeeping steps. Its example command names a version that still
exists, so it stays copy-pasteable.

Accepted cost, per step 4 of that procedure: nothing redirects a retired
version tree, so inbound https://doc.owncloud.com/server/10.15/... links
now reach the site 404 page.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Review follow-up to the version drop. Two more places named a path that
moved to extension-tests/ in #135, and one of them is the paragraph that
tells you how to *add* a server version:

`test/go-redirect.test.js` -> `extension-tests/go-redirect.test.js` in the
"Dev version numbers are provisional" note, plus the part it omitted. The
drift test compares PUBLISHED_VERSIONS against the published trees, so a
removal that misses either hand-maintained list fails. An addition does
not: add '11.1' to PUBLISHED_VERSIONS only and the drift test is happy,
while the version loop in the test file silently never covers the new
segment. The note now says to add it in both places and why.

`test/static-files.test.js` -> `extension-tests/static-files.test.js`,
same class of staleness, in the same blockquote.

The "Dropping a version" example is now `rm -r content/server/<version>`
rather than a concrete number. Naming a version that still exists made it
copy-pasteable, which is exactly the hazard: it is the one command in
these docs meant to be pasted, and pasting it deletes a live, supported
documentation tree.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Round-2 review follow-up. Each of these was a statement a reader would
act on that the code does not back.

The `<version>` placeholder introduced in the previous commit is a bash
syntax error inside a ```sh block: `<` opens a redirection and the
trailing `>` has no target, so pasting it aborts before `rm` runs. It is
`VERSION` now - a valid path component, obviously a placeholder, and
harmless if pasted. That keeps the previous commit's point (the example
must not name a live version) without breaking the command.

The release-rollover note claimed static-files.test.js fails while any of
three things disagree. It cross-checks `latest-*-version` only:
`LATEST_ATTRIBUTE_BY_COMPONENT` lists five `latest-…-version` keys and
nothing else, so `previous-*-version`, `current-server-version` and
`latest-server-download-version` are verified by no test in the suite and
a stale one of those renders site-wide on a green build. The note now says
which half is covered, and points at the gap - `previous-android-version`
already equals `latest-android-version`, which is what that looks like
when it happens.

`ui/supplemental/ui.yml` held the last `test/static-files.test.js` in the
repo, so the previous commit's claim to have finished that sweep was
wrong. It is now the only remaining reference and it is correct.

`extension-tests/` is added to the Layout tree: the README now points into
it four times without ever saying it exists.

Rebuilt and re-ran: 51 pass, 1 skip, 0 fail; public/server/ is 10.16,
11.0, latest, next; robots.txt and llms.txt still publish at the site
root, so the ui.yml comment edit did not disturb the descriptor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
@kw-tmueller
kw-tmueller force-pushed the chore/drop-server-10-15 branch from f21e600 to c7f55b2 Compare September 25, 2026 15:03
kw-tmueller pushed a commit that referenced this pull request Sep 25, 2026
The two attributes that carry a full version into the docker install
pages: `latest-server-download-version` in global-attributes.yml, which
the 11.0 page uses for the image tag in four places, and the page-local
`:docker-image-version:` on the 10.16 page.

Both pages tell the reader to pin a full version rather than use `latest`,
so the version they name has to move with the release or the advice points
at the previous one.

Caveat, deliberate: `owncloud/server` on Docker Hub has no 10.16.5 or
11.0.1 tag yet. Its newest are 11.0.0 and 10.16.4 from 2026-09-21. Both
bumps are in flight in owncloud-docker/server and the tags appear when
those merge, so this documents a tag that is queued rather than one that
resolves today. Holding the release notes for it seemed worse than a short
window where the docker snippet is ahead.

Note that nothing in the test suite guards either attribute:
static-files.test.js cross-checks only `latest-*-version`, so
`latest-server-download-version` going stale is invisible to CI. That gap
is now written down in README.md by #144.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
@oc-tmueller

Copy link
Copy Markdown
Contributor Author

Resolved — config-docs-in-sync is green

Correcting my comment above on two counts. #137 is no longer a draft: it merged as 89baa2b5,
and the push run on main for that sha
(36149916187) is green,
so the four-day drift from owncloud/core#41846/#41847 and #41858/#41859 is closed at the source.

The red that lingered here afterwards was an artifact, not the drift. A completed run pins the
merge commit computed when the run was created, so re-running it re-checks the pre-#137 base —
which is exactly what happened at 14:49, one minute after #137 merged, and it failed again on the
same two files. Only a new run helps. Rebasing onto main produced one:
36151622869 is green.

The rebase carried the three commits over untouched — git range-diff reports all three as
identical, and all three are re-signed and verified. So the diff to review is unchanged; only the
base moved.

@LukasHirt

LukasHirt commented Sep 25, 2026 •

Copy link
Copy Markdown
Contributor

Approved but since this drops existing content I'll leave merging it up to you in case you want to have some specific timing for it.

LukasHirt pushed a commit that referenced this pull request Sep 25, 2026
* docs: add release notes for ownCloud Classic 10.16.5 and 11.0.1

Both were tagged on 2026-09-25 and the release notes stopped at 11.0.0 and
10.16.4, so administrators had no entry for either. Both are security
releases.

Entries are grouped by the prefix core's own changelog entry carries -
Security, Change, Bugfix - rather than re-classified here, and follow the
existing patch-release template: the "Dear ownCloud administrator"
paragraph, an IMPORTANT admonition, then discrete Security Fixes / Changes
/ Notable Bugfixes sections. 11.0.1 has 15 entries (3/3/9), 10.16.5 has 12
(4/1/7). Each is cited with the PR the changelog entry itself cites, which
for the 10.16 line is the pair of master PR and 10.16 backport.

Two items got more than a bullet because they change what an administrator
will observe:

The Imagick coder pinning (#41834) changes which files get a thumbnail at
all. Media types come from the file name extension, so a file whose
extension does not match its content now falls back to a media type icon
instead of being rendered. That is in a NOTE with the affected extension
list, which of those providers are registered on a stock install, and the
font extensions that behave differently. It is the one part of either
release that can look like a regression.

The release tarball repackaging (#41824) matters to anyone who runs
`occ integrity:check-app` or an anti-virus gate over the tarball, since
`files_antivirus` was shipping its EICAR acceptance data.

No Known Issues subsection: no patch-release section since 10.15.0 has one.

Verified against the tags rather than transcribed by eye: the package
lists and CVE list were diffed programmatically against
changelog/10.16.5_2026-09-25/ and changelog/11.0.1_2026-09-25/ in
owncloud/core and match exactly (26, 22 and 17 items). All 36 cited
core PR/issue numbers were resolved through the API and exist. Worth
noting for a future reader: #41676 really is the checkPropFind priority
fix even though its title reads "chore(deps): update PHP dependencies" -
that PR bundled both, which is why the citation looks wrong and is not.

Rendered and checked in the built site: both sections appear in the right
descending order, the toc picks them up (53 entries), the NOTE and
IMPORTANT admonitions render as admonitions, and no attribute reference or
list continuation was left unresolved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>

* docs: pin the docker examples to 10.16.5 and 11.0.1

The two attributes that carry a full version into the docker install
pages: `latest-server-download-version` in global-attributes.yml, which
the 11.0 page uses for the image tag in four places, and the page-local
`:docker-image-version:` on the 10.16 page.

Both pages tell the reader to pin a full version rather than use `latest`,
so the version they name has to move with the release or the advice points
at the previous one.

Caveat, deliberate: `owncloud/server` on Docker Hub has no 10.16.5 or
11.0.1 tag yet. Its newest are 11.0.0 and 10.16.4 from 2026-09-21. Both
bumps are in flight in owncloud-docker/server and the tags appear when
those merge, so this documents a tag that is queued rather than one that
resolves today. Holding the release notes for it seemed worse than a short
window where the docker snippet is ahead.

Note that nothing in the test suite guards either attribute:
static-files.test.js cross-checks only `latest-*-version`, so
`latest-server-download-version` going stale is invisible to CI. That gap
is now written down in README.md by #144.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>

* docs: fix three accuracy defects in the new release notes

Review follow-up on the 10.16.5 and 11.0.1 sections.

The three closing paragraphs of 10.16.5's dependency security bullet
rendered *inside* the last package row. A `+` continuation after a `**`
item attaches to that item, not to its parent, so "This closes sixteen
advisories…", the dom-sanitizer paragraph and the php-jwt paragraph all
appeared indented under `symfony/routing (v5.4.52 to v5.4.53)` - reading as
if sixteen CVEs, the branch pin and the php-jwt exception were all about
symfony/routing. The prose now precedes the nested list, which is the shape
the 10.16.2 bullet already uses. Verified in the built page: the nested
list is exactly the seven package rows and nothing else.

The `checkPropFind` bullet linked #41676, which is **closed and was never
merged** (`merged: false`, head `sabre-update-20260711`). The change
shipped via #41797, merge commit 23ccb865d6 on 2026-08-30, which carried
`changelog/unreleased/41676` and so kept the abandoned PR's number as the
entry's filename. Core's changelog cites the dead number; reproducing it
faithfully would have sent every reader to an unrelated closed PR, so the
link is #41797 now. This also corrects the previous commit message, which
argued #41676 was right on the strength of its file list alone - the files
matched because that PR authored the fix, but it is not how the fix landed.

10.16.5's Oracle path-hash bullet said the notice is what "PHP 8 reports",
in a section whose release line supports PHP 7.4 only - so it described a
symptom no 10.16 installation can see. It now says that outright, and that
the stored hash was never wrong either way because `md5(null)` coerces to
`md5('')`. The 11.0.1 wording is untouched, where PHP 8 is the runtime and
the original sentence is correct.

Rebuilt: 51 pass, 1 skip, 0 fail. #41676 no longer appears anywhere in the
page.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>

* docs: tighten two version claims and credit the closed #41676

Round-2 review follow-up, both prose only.

The Oracle path-hash deprecation is PHP **8.1**'s - the RFC deprecating
null for non-nullable internal parameters - so PHP 8.0 is silent too and
"appears on PHP 8" over-claimed in a sentence whose whole point is runtime
precision. It also read as though the 10.16 test suite surfaces it, but
that suite pins 7.4 on this branch and 7.4 raises nothing; it was found on
the 11.x line under PHP 8.3. Both are now stated as such.

The `checkPropFind` bullet now names #41676 as well. It is closed and
unmerged, so it cannot be the citation, but core's changelog cites it and a
reader cross-referencing the two sources otherwise finds nothing that
matches - and #41797 is a dependency-bump PR cited twice in the same
section. The bullet says which PR authored the change and which one shipped
it.

Also corrected: the fix ordered `checkPropFind` ahead of listeners of
*equal priority*, not "alphabetically" - sabre/event compares priority and
nothing else.

Rebuilt: 51 pass, 1 skip, 0 fail, no unresolved attribute references.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>

* docs: cut the per-entry breakdown from the 10.16.5 and 11.0.1 notes

Both sections are now the heading, the standard "Dear ownCloud
administrator" paragraph pointing at the changelog, and a one-line
security-release notice matching the wording 10.16.4 already uses.

The enumerated Security Fixes / Changes / Notable Bugfixes blocks are gone:
they restated the changelog at length, and counting the security fixes in
the banner made these releases read as far more alarming than the ones
either side of them. The changelog is where that detail belongs and the
intro paragraph already links it.

That also drops the preview-behaviour NOTE and the dependency and CVE
tables. 77 lines become 6 for 11.0.1, 70 become 6 for 10.16.5.

Rebuilt: 51 pass, 1 skip, 0 fail. Both sections still appear in the toc,
and neither now renders a sub-heading, list or admonition other than the
one IMPORTANT.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>

---------

Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <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.

2 participants