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/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/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 4a4bcc118..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, \ @@ -62,10 +64,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 +154,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 +204,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/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 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/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