From 0e532667729f7aa26aa6d59b03c9876bb089dc45 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <1005065+DeepDiver1975@users.noreply.github.com> Date: Thu, 30 Jul 2026 18:03:36 +0200 Subject: [PATCH 1/3] docs: move next to 11.0 and require explicit docker image versions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ownCloud Classic 11.0.0 is released, so master no longer documents an unreleased version. Rename the component version from `next` to `11.0` and drop the `prerelease` key, which makes Antora pick this branch as the component's `latest` and removes the `next` version segment. This also fixes the version display on the docker installation page. The `.env` example interpolates `latest-server-download-version`, which was pinned to the 10.16 line, so the future-11 page told admins to run a 10.16.4 image. The local build attributes in `site.yml` and `global-attributes.yml` now name 11.0 / 11.0.0 accordingly. Every documented image reference now carries an explicit version tag and the `latest` tag is no longer recommended anywhere: `owncloud/server:latest` tracks the 10.16 line rather than the newest release, and no rolling major or minor tag exists at all, so following it from the 11 docs silently installs 10.16.4. This covers the untagged quick-evaluation `docker run`, the `OWNCLOUD_IMAGE` setting description, the commented-out memcached service and the selenium and inbucket images in the UI testing guide. Three defects found while verifying the documented commands against the published `owncloud/server:11.0.0` image: * 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, so a verbatim copy produced a blank admin account. * `mysql_upgrade` was documented against the `owncloud` service, but the binary ships with the database image and only exists in `mariadb`. * The ImageMagick command-line tools are not part of the image, so the preview prerequisite checks cannot succeed as written. The page now points at the guide for building your own image. Finally, adjust the version-branch procedure to the new model, where master carries the released version instead of `next`, and replace its stale `.drone.star` instructions with the CI workflow branch list that actually governs which branches get built. Signed-off-by: Thomas Müller <1005065+DeepDiver1975@users.noreply.github.com> --- .github/workflows/ci.yml | 1 - antora.yml | 7 +++---- docs/new-version-branch.md | 11 ++++++----- global-attributes.yml | 8 ++++---- .../examples/installation/docker/docker-compose.yml | 2 +- .../examples/installation/docker/dot.env | 2 ++ .../configuration/files/previews_configuration.adoc | 2 ++ .../pages/installation/installing_with_docker.adoc | 12 ++++++++---- .../maintenance/upgrading/database_upgrade.adoc | 4 ++-- .../developer_manual/pages/testing/ui-testing.adoc | 10 +++++----- site.yml | 12 ++++++------ 11 files changed, 39 insertions(+), 32 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 6bd500084..0fa195aeb 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -5,7 +5,6 @@ on: branches: - master - '10.16' - - '10.15' tags: - '**' pull_request: diff --git a/antora.yml b/antora.yml index cb936948a..794fa5d2f 100644 --- a/antora.yml +++ b/antora.yml @@ -1,7 +1,6 @@ name: server title: ownCloud Classic -version: next -prerelease: true +version: '11.0' start_page: ROOT:index.adoc nav: - modules/ROOT/partials/nav.adoc @@ -11,7 +10,7 @@ asciidoc: latest-server-version: {page-component-version} # do not change, this is the value of the version key previous-server-version: {page-component-version} # do not change, this is the value of the version key current-server-version: {page-component-version} # do not change, this is the value of the version key - minimum-php-printed: '8.1.0' - recommended-php-version: '8.1' # note: admin docs + minimum-php-printed: '8.3.0' + recommended-php-version: '8.3' # note: admin docs format: 'html' # this attribute is a necessary legacy config-sample: configuration/server/config_sample_php_parameters.adoc diff --git a/docs/new-version-branch.md b/docs/new-version-branch.md index 6527ddc8b..18d1a0faa 100644 --- a/docs/new-version-branch.md +++ b/docs/new-version-branch.md @@ -1,6 +1,8 @@ # Create a New Version Branch -When doing a new release of this product documentation, a new version branch must be created based on `master`. It is necessary to do this in steps. Keep in mind that we only process master (version `next`) and the latest two named versions. Patch versions are excluded from this process and can be added in the product repo at any time without further notice. For patch versions, only content changes need to be added if any. +When doing a new release of this product documentation, a new version branch must be created based on `master`. It is necessary to do this in steps. Keep in mind that we only process master and the latest named version. Patch versions are excluded from this process and can be added in the product repo at any time without further notice. For patch versions, only content changes need to be added if any. + +**Note that `master` carries the *released* version, not an unreleased `next`.** With ownCloud Classic 11.0.0, the `next` version was renamed to `11.0` and the `prerelease` key was dropped from `antora.yml`; there is no `next` version segment for this product any more. Antora selects the newest non-prerelease version of a component as its `latest`, so master being a released version is what makes `/server/latest/` point at the current documentation. Consequently a new version branch *freezes the outgoing version* off master, and master is then bumped to the new one — the reverse of the former `next`-based flow. Note that the `latest` version pointer mentioned below is virtual and not part of Antora but created by the webserver and redirects to the latest versioned product automatically. @@ -16,7 +18,7 @@ Enable pushing a new branch. This step creates the branch locally, necessary for content changes and for the repo building process. 1. Create a new `x.y` branch based on latest `origin/master` -1. In `.drone.star` set `latest_version` to `x.y` (on top in section `def main(ctx)`). +1. In `.github/workflows/ci.yml`, add the new `x.y` branch to `on.push.branches` and to `on.pull_request.branches`, and remove the branch that is being dropped. This is the list that decides which branches CI builds — there is no `.drone.star` in this repo any more. 1. Check in `site.yml` in section `content.sources` that the following value is set: `- url: .` and in `content.sources.url` the following value is set: `- HEAD`. 1. In `antora.yml`, set the `version:` key on top to the same as the branch name like `x.y`. Each branch must have it's unique version! 1. In `antora.yml`, in section `asciidoc.attributes`, DO NOT adjust relevant `-version` keys. They are required for local building. @@ -36,9 +38,8 @@ The branch has been pushed, add it to the rule set for protected version branche This step is necessary to update the building process for content changes in this repo. 1. Create a new `changes_necessary_for_x.y` branch based on latest `origin/master`. -1. In `.drone.star` set `latest_version` to `x.y` (on top in section `def main(ctx)`). -1. In `antora.yml`, check if the `version:` key is set to `next`. -1. In `site.yml` and in `antora.yml`, DO NOT adjust relevant `-version` keys. +1. In `antora.yml`, set the `version:` key to the version master now carries. Do not add a `prerelease` key — master holds a released version, see the note at the top. +1. In `site.yml` and in `antora.yml`, adjust the relevant `-version` keys to master's new version. They are only used for local building, but they must match the `version:` key so that a local build renders the same values as the assembled site. 1. Run a build by entering `npm run antora-local`. No build errors or warnings should occur. 1. Commit changes and push them. (Check the branch protection rules upfront so that the push passes.) 1. Create a Pull Request `Changes necessary for x.y`, see the [text suggestion](#text-suggestion-for-step-4) below. When CI is green, all is done correctly, merge the PR when approved. This merge does NOT add the version to the main building process. You can now add at any time content changes to this version. diff --git a/global-attributes.yml b/global-attributes.yml index e2ac6d4b5..c9874ef05 100644 --- a/global-attributes.yml +++ b/global-attributes.yml @@ -25,10 +25,10 @@ latest-docs-version: 'next' previous-docs-version: 'next' # server - latest-server-version: '10.15' - previous-server-version: '10.14' - latest-server-download-version: '10.16.4' - current-server-version: '10.15' + latest-server-version: '11.0' + previous-server-version: '10.16' + latest-server-download-version: '11.0.0' + current-server-version: '11.0' oc-changelog-url: 'https://owncloud.com/changelog/server/' oc-install-package-url: 'https://download.owncloud.com/server/stable/?sort=time&order=asc' oc-examples-server-url: 'https://owncloud.install.com/owncloud' diff --git a/modules/admin_manual/examples/installation/docker/docker-compose.yml b/modules/admin_manual/examples/installation/docker/docker-compose.yml index a43762511..93e8b42f3 100644 --- a/modules/admin_manual/examples/installation/docker/docker-compose.yml +++ b/modules/admin_manual/examples/installation/docker/docker-compose.yml @@ -89,7 +89,7 @@ services: # See the caching configuration documentation for more details. # memcached: -# image: memcached:latest +# image: memcached:1.6 # container_name: owncloud_memcached # restart: always # ports: diff --git a/modules/admin_manual/examples/installation/docker/dot.env b/modules/admin_manual/examples/installation/docker/dot.env index 3e0ed5b46..649bd3abe 100644 --- a/modules/admin_manual/examples/installation/docker/dot.env +++ b/modules/admin_manual/examples/installation/docker/dot.env @@ -2,6 +2,8 @@ OWNCLOUD_IMAGE={latest-server-download-version} OWNCLOUD_DOMAIN=localhost OWNCLOUD_TRUSTED_DOMAINS=localhost OWNCLOUD_OVERWRITE_CLI_URL=http://localhost +ADMIN_USERNAME=admin +ADMIN_PASSWORD=admin HTTP_PORT={std-port-http} MARIADB_IMAGE=10.11 REDIS_IMAGE=7 diff --git a/modules/admin_manual/pages/configuration/files/previews_configuration.adoc b/modules/admin_manual/pages/configuration/files/previews_configuration.adoc index e0cb16537..9a60b1391 100644 --- a/modules/admin_manual/pages/configuration/files/previews_configuration.adoc +++ b/modules/admin_manual/pages/configuration/files/previews_configuration.adoc @@ -64,6 +64,8 @@ When defining your own preview providers, some things need to be considered. For Starting with version 7 of ImageMagick, additional file formats like SVG or HEIC and many others can be processed. +NOTE: The ImageMagick command-line tools like `convert` are not part of the ownCloud image provided. To use the providers described here, build your own image based on it, see xref:installation/create_own_image.adoc[Create an own Docker Image]. The same applies to `ghostscript` and `ffmpeg` mentioned below. + You can check your ImageMagick version, if installed in your image, by issuing the following command: [source,docker] diff --git a/modules/admin_manual/pages/installation/installing_with_docker.adoc b/modules/admin_manual/pages/installation/installing_with_docker.adoc index 4a4bcc118..bd3ccedc4 100644 --- a/modules/admin_manual/pages/installation/installing_with_docker.adoc +++ b/modules/admin_manual/pages/installation/installing_with_docker.adoc @@ -62,10 +62,10 @@ For testing purposes or a quick hands-on to get familiar with the look and feel, [source,docker,subs="attributes+"] ---- -docker run --rm --name oc-eval -d -p{std-port-http}:{std-port-http} owncloud/server +docker run --rm --name oc-eval -d -p{std-port-http}:{std-port-http} owncloud/server:{latest-server-download-version} ---- -This starts a docker container with the name "oc-eval" in the background (option `-d`). `owncloud/server` is the docker image downloaded from Docker Hub. If you don't start the container with option `-d`, the logs will be displayed in the shell. If you are running it in the background as in the example above, you can display the logs with the command: +This starts a docker container with the name "oc-eval" in the background (option `-d`). `owncloud/server:{latest-server-download-version}` is the docker image downloaded from Docker Hub. Always name an explicit version tag, see the note on the `OWNCLOUD_IMAGE` setting below. If you don't start the container with option `-d`, the logs will be displayed in the shell. If you are running it in the background as in the example above, you can display the logs with the command: [source,docker] ---- @@ -152,8 +152,9 @@ Only a few settings are required, these are: | Example | `OWNCLOUD_IMAGE` -| The ownCloud version -a| `{latest-server-download-version}` or `latest` +| The ownCloud version. + +Always use an explicit version, never `latest`. +a| `{latest-server-download-version}` | `OWNCLOUD_DOMAIN` *^1^* a| Only for use with a single ownCloud domain + @@ -201,6 +202,9 @@ a| xref:{config-sample}#override-cli-url[OWNCLOUD_OVERWRITE_CLI_URL] + [NOTE] ==== +* `OWNCLOUD_IMAGE` + +Pin this to a full version like `{latest-server-download-version}`. Do not use the `latest` tag: it does not track the newest ownCloud Classic release, and there are no rolling major or minor tags either. Using an explicit version also means you decide when an upgrade happens, rather than a container restart deciding it for you. + * `ADMIN_USERNAME` and `ADMIN_PASSWORD` + The values will not change between deploys even if you change them in the `.env` file. + These environment variables are used to define the admin user *for system setup and first logon*. Once set, the values are fixed. diff --git a/modules/admin_manual/pages/maintenance/upgrading/database_upgrade.adoc b/modules/admin_manual/pages/maintenance/upgrading/database_upgrade.adoc index 246475ac2..8a1c3593e 100644 --- a/modules/admin_manual/pages/maintenance/upgrading/database_upgrade.adoc +++ b/modules/admin_manual/pages/maintenance/upgrading/database_upgrade.adoc @@ -54,11 +54,11 @@ Configure your web proxy server to prevent users from accessing ownCloud via the + -- Follow the instructions in the respective {upgrade-mariadb-url}[Upgrading MariaDB] guide to upgrade MariaDB. + -If required, run the `mysql_upgrade` command when using a compose setup including MySQL. +If required, run the `mysql_upgrade` command when using a compose setup including MySQL. Note that the command ships with the database image, so it has to be run in the `mariadb` service and not in the `owncloud` one. [source,bash] ---- -docker compose exec owncloud mysql_upgrade -uroot -p +docker compose exec mariadb mysql_upgrade -uroot -p ---- -- diff --git a/modules/developer_manual/pages/testing/ui-testing.adoc b/modules/developer_manual/pages/testing/ui-testing.adoc index d93bbfdae..a0432885e 100644 --- a/modules/developer_manual/pages/testing/ui-testing.adoc +++ b/modules/developer_manual/pages/testing/ui-testing.adoc @@ -31,9 +31,9 @@ Pull any or all of these Docker containers: ---- docker pull selenium/standalone-chrome:3.141.59-oxygen docker pull selenium/standalone-chrome-debug:3.141.59-oxygen -docker pull selenium/standalone-firefox -docker pull selenium/standalone-firefox-debug -docker pull inbucket/inbucket +docker pull selenium/standalone-firefox:3.141.59-oxygen +docker pull selenium/standalone-firefox-debug:3.141.59-oxygen +docker pull inbucket/inbucket:3.1.1 ---- * A `vnc` viewer installed (in order to view the browser action as the UI tests run). For example: @@ -62,7 +62,7 @@ taken to do the test. [source,console] ---- -docker run -p 4445:4444 -p 5900:5900 -v /dev/shm:/dev/shm selenium/standalone-chrome-debug +docker run -p 4445:4444 -p 5900:5900 -v /dev/shm:/dev/shm selenium/standalone-chrome-debug:3.141.59-oxygen ---- Ports on the Selenium Docker IP address are mapped to `localhost` so they can be accessed by the tests and the `vnc` viewer. @@ -71,7 +71,7 @@ Ports on the Selenium Docker IP address are mapped to `localhost` so they can be [source] ---- -docker run -p 2500:2500 -p 9000:9000 inbucket/inbucket +docker run -p 2500:2500 -p 9000:9000 inbucket/inbucket:3.1.1 ---- Ports on the InBucket docker IP address are mapped to `localhost` so they can be accessed by the tests. diff --git a/site.yml b/site.yml index 29f35df45..6dd4e44e8 100644 --- a/site.yml +++ b/site.yml @@ -24,12 +24,12 @@ asciidoc: # branch-specific-variables: 'see antora.yml' # global attributes loaded via antora extension # server - # note that the version attributes just need to be present and have next as key - # as they are just here for the test build - latest-server-version: 'next@' # do not change, soft set, correctly defined via antora.yml - previous-server-version: 'next@' # do not change, soft set, correctly defined via antora.yml - latest-server-download-version: '10.16.4' - current-server-version: 'next@' # do not change, soft set, correctly defined via antora.yml + # note that the version attributes just need to be present and match the version key + # of antora.yml as they are just here for the test build + latest-server-version: '11.0@' # do not change, soft set, correctly defined via antora.yml + previous-server-version: '11.0@' # do not change, soft set, correctly defined via antora.yml + latest-server-download-version: '11.0.0' + current-server-version: '11.0@' # do not change, soft set, correctly defined via antora.yml extensions: - ./ext-asciidoc/tabs.js - ./ext-asciidoc/remote-include-processor.js From 1d75a0ad7fc568f6b5e1e83ddc99f27112442aa4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <1005065+DeepDiver1975@users.noreply.github.com> Date: Thu, 30 Jul 2026 18:33:31 +0200 Subject: [PATCH 2/3] docs: alias the page paths dropped since 10.16 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Four pages that exist in 10.16 have no equivalent here, so their URLs start 404ing the moment this branch becomes the `latest` server version: `installation/index.adoc` and `installation/source_installation.adoc` (this is a docker-only release, so there is no manual or source installation), `installation/configuration_notes_and_tips.adoc` (now `configuration/important_notes.adoc`) and `maintenance/migrating.adoc` (now under `maintenance/migrate_owncloud/`). These are not merely 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 emits via `buildDocLinkToKey`, and `owncloud/docs` asserts in CI that every mapped target exists in the built site. Aliasing them keeps those links working and keeps the docs build green, which a mapping change would not. Signed-off-by: Thomas Müller <1005065+DeepDiver1975@users.noreply.github.com> --- modules/admin_manual/pages/configuration/important_notes.adoc | 3 ++- .../pages/installation/installing_with_docker.adoc | 2 ++ .../pages/maintenance/migrate_owncloud/migrating.adoc | 1 + 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/modules/admin_manual/pages/configuration/important_notes.adoc b/modules/admin_manual/pages/configuration/important_notes.adoc index c7155ff36..a0aa63f23 100644 --- a/modules/admin_manual/pages/configuration/important_notes.adoc +++ b/modules/admin_manual/pages/configuration/important_notes.adoc @@ -1,6 +1,7 @@ = Important Configuration Notes :toc: right -:page-aliases: installation/configuration_notes.adoc +:page-aliases: installation/configuration_notes.adoc, \ +installation/configuration_notes_and_tips.adoc :description: This page provides some important configuration notes. == Introduction diff --git a/modules/admin_manual/pages/installation/installing_with_docker.adoc b/modules/admin_manual/pages/installation/installing_with_docker.adoc index bd3ccedc4..be703886f 100644 --- a/modules/admin_manual/pages/installation/installing_with_docker.adoc +++ b/modules/admin_manual/pages/installation/installing_with_docker.adoc @@ -2,6 +2,8 @@ :toc: right :description: ownCloud can be installed using the official ownCloud Docker image. :page-aliases: enterprise/installation/install.adoc, \ +installation/index.adoc, \ +installation/source_installation.adoc, \ installation/manual_installation/manual_installation.adoc, \ installation/quick_guides/ubuntu_20_04.adoc, \ installation/quick_guides/ubuntu_22_04.adoc, \ diff --git a/modules/admin_manual/pages/maintenance/migrate_owncloud/migrating.adoc b/modules/admin_manual/pages/maintenance/migrate_owncloud/migrating.adoc index fade75e40..77e5f1d34 100644 --- a/modules/admin_manual/pages/maintenance/migrate_owncloud/migrating.adoc +++ b/modules/admin_manual/pages/maintenance/migrate_owncloud/migrating.adoc @@ -1,5 +1,6 @@ = Migrating an Instance :toc: right +:page-aliases: maintenance/migrating.adoc :description: There are several situations where ownCloud needs to be migrated. == Introduction From d3da5a801e717dbe3aa64dc1c0089518b25b986d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <1005065+DeepDiver1975@users.noreply.github.com> Date: Fri, 31 Jul 2026 10:32:25 +0200 Subject: [PATCH 3/3] revert(docs): unpin the third-party docker images again MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The explicit-version requirement is about `owncloud/server` only: its `latest` tag does not track the newest ownCloud Classic release and there are no rolling major or minor tags, so following it from the 11 docs installs a version the docs do not describe. That reasoning does not carry over to the third-party images. Pinning the commented-out memcached service in the compose example and the selenium and inbucket images in the UI testing guide fixes no documented-version mismatch and only adds pins that nothing in this repo keeps current, so restore them to their previous form. The two `standalone-chrome*` pins stay, they predate this and exist because of owncloud/core#35444. Signed-off-by: Thomas Müller <1005065+DeepDiver1975@users.noreply.github.com> --- .../examples/installation/docker/docker-compose.yml | 2 +- modules/developer_manual/pages/testing/ui-testing.adoc | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/modules/admin_manual/examples/installation/docker/docker-compose.yml b/modules/admin_manual/examples/installation/docker/docker-compose.yml index 93e8b42f3..a43762511 100644 --- a/modules/admin_manual/examples/installation/docker/docker-compose.yml +++ b/modules/admin_manual/examples/installation/docker/docker-compose.yml @@ -89,7 +89,7 @@ services: # See the caching configuration documentation for more details. # memcached: -# image: memcached:1.6 +# image: memcached:latest # container_name: owncloud_memcached # restart: always # ports: diff --git a/modules/developer_manual/pages/testing/ui-testing.adoc b/modules/developer_manual/pages/testing/ui-testing.adoc index a0432885e..d93bbfdae 100644 --- a/modules/developer_manual/pages/testing/ui-testing.adoc +++ b/modules/developer_manual/pages/testing/ui-testing.adoc @@ -31,9 +31,9 @@ Pull any or all of these Docker containers: ---- docker pull selenium/standalone-chrome:3.141.59-oxygen docker pull selenium/standalone-chrome-debug:3.141.59-oxygen -docker pull selenium/standalone-firefox:3.141.59-oxygen -docker pull selenium/standalone-firefox-debug:3.141.59-oxygen -docker pull inbucket/inbucket:3.1.1 +docker pull selenium/standalone-firefox +docker pull selenium/standalone-firefox-debug +docker pull inbucket/inbucket ---- * A `vnc` viewer installed (in order to view the browser action as the UI tests run). For example: @@ -62,7 +62,7 @@ taken to do the test. [source,console] ---- -docker run -p 4445:4444 -p 5900:5900 -v /dev/shm:/dev/shm selenium/standalone-chrome-debug:3.141.59-oxygen +docker run -p 4445:4444 -p 5900:5900 -v /dev/shm:/dev/shm selenium/standalone-chrome-debug ---- Ports on the Selenium Docker IP address are mapped to `localhost` so they can be accessed by the tests and the `vnc` viewer. @@ -71,7 +71,7 @@ Ports on the Selenium Docker IP address are mapped to `localhost` so they can be [source] ---- -docker run -p 2500:2500 -p 9000:9000 inbucket/inbucket:3.1.1 +docker run -p 2500:2500 -p 9000:9000 inbucket/inbucket ---- Ports on the InBucket docker IP address are mapped to `localhost` so they can be accessed by the tests.