docs: move next to 11.0 and require explicit docker image versions

[DeepDiver1975]

ownCloud Classic 11.0.0 is released, so master no longer documents an unreleased version.

Version move

• antora.yml: version: next -> version: '11.0', prerelease: true dropped. Antora picks the newest non-prerelease version of a component as its latest, so this branch becomes /server/latest/ and the next segment disappears.
• No 11.0 branch is cut and no new next is created.
• minimum-php-printed / recommended-php-version were still on 8.1. core@v11.0.0 lib/base.php refuses PHP_VERSION_ID < 80300 and refuses >= 80600, and the image ships PHP 8.3.6, so both move to 8.3.

Needs the companion PR in owncloud/docs to land right after this one, which drops '10.15' from the docs-server content sources, moves the server -version attributes and updates PUBLISHED_VERSIONS in go-redirect.js.

Version display fix

The docker installation page rendered OWNCLOUD_IMAGE=10.16.4 on the future-11 docs. The .env example interpolates latest-server-download-version, and the value that wins comes from the aggregating playbook, which was pinned to the 10.16 line. The local build attributes in site.yml and global-attributes.yml now name 11.0 / 11.0.0.

No more :latest

owncloud/server:latest is 10.16.4, not 11.0.0, and there is no rolling 11.0 or 11 tag at all, so a reader following latest from the 11 docs silently installs 10.16.4. Every documented owncloud/server reference now carries an explicit version tag:

• the untagged quick-evaluation docker run
• the OWNCLOUD_IMAGE setting description, which recommended latest as an alternative

This applies to owncloud/server only. An earlier revision of this PR also pinned the third-party images (the commented-out memcached service in the compose example, the selenium and inbucket images in the UI testing guide); those pins are reverted, since they fix no documented-version mismatch and nothing in this repo keeps them current.

Defects found while verifying against the published image

I ran the documented flows against owncloud/server:11.0.0 (both the quick-eval container and this repo's own compose example). The stack came up healthy - status.php reports versionstring 11.0.0, integrity:check-core is INTACT - and docker compose exec owncloud occ ..., docker exec --user www-data oc-eval occ ..., the two /bin/bash variants and docker compose run --rm ... /usr/bin/owncloud bash all work as documented. Three things did not:

1. The .env example omitted ADMIN_USERNAME and ADMIN_PASSWORD, although the compose file maps both into the container and the settings table lists them as required. docker compose config on the verbatim files warns "ADMIN_USERNAME" variable is not set and emits OWNCLOUD_ADMIN_USERNAME: "", so a copy/paste install got a blank admin account.
2. mysql_upgrade was documented against the owncloud service. The binary ships with the database image and only exists in mariadb.
3. The ImageMagick command-line tools are not in the image, so the preview prerequisite checks cannot succeed as written. create_own_image.adoc already lists preview configuration as a reason to build your own image, but nothing linked back; that link is now there.

Process doc

docs/new-version-branch.md assumed master always carries an unreleased next, and instructed edits to .drone.star, which no longer exists in this repo. Both are corrected, naming the CI workflow branch list as the real control.

Testing

npm run antora-local produces the same two pre-existing ocis: cross-component xref errors as master and no new ones. In the built output: the version segment is 11.0, the page renders OWNCLOUD_IMAGE=11.0.0 and owncloud/server:11.0.0, the admin credentials are present, and no or latest remains.

🤖 Generated with Claude Code

[DeepDiver1975]

Added a second commit (docs: alias the page paths dropped since 10.16) found while building the aggregated site with this branch as latest.

Four pages that exist in 10.16 have no equivalent here, so their URLs would start 404ing the moment this becomes the latest server version: installation/index.adoc and installation/source_installation.adoc (docker-only release), installation/configuration_notes_and_tips.adoc (now configuration/important_notes.adoc) and maintenance/migrating.adoc (now under maintenance/migrate_owncloud/).

These are not just stale internal links — all four are go.php redirect keys (admin-install, admin-source_install, admin-php-fpm, admin-untrusted-domains) that every deployed ownCloud server keeps emitting via buildDocLinkToKey, and owncloud/docs asserts in CI that every mapped target exists in the built site. Adding page-aliases keeps those inbound links working and keeps the docs build green; remapping the keys would only have done the latter.

Verified in a full aggregated build: all four legacy paths now emit redirect stubs to the new pages, 0 build errors, and npm test in owncloud/docs passes 15/15.