docs: add release notes for ownCloud Classic 10.16.5 and 11.0.1

[oc-tmueller]

Why

owncloud/core tagged v10.16.5 and v11.0.1 on 2026-09-25. The release notes stopped at 11.0.0 and 10.16.4, so administrators had no entry for either.

What

Deliberately short. Each new section is the heading, the standard "Dear ownCloud administrator" paragraph pointing at {oc-changelog-url}, and a one-line security-release notice using the wording 10.16.4 already uses:

== Changes in 11.0.1

Dear ownCloud administrator, find below the changes and known issues in ownCloud Classic 11.0.1 that need your attention. You can also read the {oc-changelog-url}[full ownCloud Classic changelog] for further details on what has changed.

IMPORTANT: This is a security release. Upgrading is strongly recommended for all installations.

No per-entry breakdown. An earlier revision of this branch enumerated all 27 changelog entries across the two releases with prose, dependency tables and the CVE list. That restated the changelog at length, and counting the security fixes in the banner made these two releases read as far more alarming than the ones either side of them. The changelog is where that detail belongs, and the intro paragraph links it.

⚠️ Read the diff, not the commit series. The branch adds the long form and then removes it again, because the shortening came after review. The net change is +14 / -2 across 3 files; force-push is blocked by the org ruleset, so the history cannot be squashed here.

Docker image pins

latest-server-download-version → 11.0.1 (the 11.0 install page uses it in four places plus dot.env) and the page-local :docker-image-version: → 10.16.5 on the 10.16 page. Both pages tell the reader to pin a full version instead of using latest, so the version they name has to move with the release.

Both tags are live on Docker Hub as of 2026-09-25 13:09Z, via owncloud-docker/server#714 (10.16.5) and owncloud-docker/server#715 (11.0.1) — so nothing here points at a tag that does not resolve.

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 written down in README.md by #144.

Verification

npm run antora && npm test → 51 pass, 1 skip, 0 fail. Both new sections appear in the TOC in the right descending order and render nothing but the one IMPORTANT — no sub-heading, list or other admonition. The two docker pages render owncloud/server:11.0.1 and owncloud/server:10.16.5 respectively.

config-docs-in-sync is red for a pre-existing reason unrelated to this PR and is not a required check — see the comment below.

Follow-ups this PR does not take

• #715 introduces floating 11.0 and 11 tags that 11.0.0 never had (it only ever published its exact version). The 11.0 docker page could gain a sentence about them. Note latest deliberately stays on the 10.x line, so that page's existing "do not use latest" warning is correct as it stands.
• Possible access-control regression in the shipped v10.16.5, found while checking a citation and not demonstrated at runtime. v10.16.5 bumps sabre/event 5.1.7 → 5.1.9 but does not carry the method:PROPFIND priority fix that 11.0.1 has (, 99). 5.1.9 (baadb7cf) replaced array_multisort, which tie-broke on the listener values, with usort on priority alone. Sabre\DAV\Server::__construct() adds CorePlugin before ownCloud adds FilesPlugin, both at the default priority, and CorePlugin::httpPropFind() ends in return false, which interrupts the chain — while FilesPlugin::checkPropFind() is what throws NotFound when a SharedStorage share lacks PERMISSION_READ, i.e. it guards create-only / file-drop shares. Worth stressing that usort is unstable on PHP 7.4, the only version 10.16 supports, so the honest claim is "the ordering that fix guarantees is no longer guaranteed", not "the check is bypassed". A PROPFIND against a file-drop share on a 10.16.5 container settles it.

🤖 Generated with Claude Code

[oc-tmueller]

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]

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 only re-checks the pre-#137
base. Only a new run helps. Rebasing onto main produced one:
36151676677 is green.

The rebase carried the five commits over untouched — git range-diff reports all five as
identical, and all five are re-signed and verified. So the diff to review is unchanged; only the
base moved. The note above still applies: read the diff, not the commit series.