Updated documentation to handle the conf folder on upgrades (#40175)

Closes #40046
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
This commit is contained in:
Alexander Schwartz
2025-06-03 16:14:11 +02:00
committed by GitHub
parent 6238814625
commit 2b2d7bbcbe
2 changed files with 13 additions and 1 deletions

View File

@@ -132,3 +132,11 @@ a new parameter `subGroupsCount` was introduced to the following endpoints:
With this parameter, clients can decide whether the count should be returned to each individual group returned. To not break existing deployments,
this parameter defaults to `true` so that the count is returned if the parameter is not set.
=== Upgrade procedure changed for the distribution
If you are upgrading {project_name} by downloading the distribution, the upgrade procedure has been changed. Previously it recommended copying over the contents from the `conf/` folder from the old to the new installation.
The new procedure recommends to re-apply any changes to `cache-ispn.xml` or a custom cache configuration based on the file included in the new version.
This prevents accidentally downgrading functionality, for example, by using an old `cache-ispn.xml` file from a previous version.

View File

@@ -11,4 +11,8 @@ from the {project_name} website.
+
After extracting this file, you should have a directory that is named `{archivebasename}-{project_version}`.
. Move this directory to the desired location.
. Copy `conf/`, `providers/` and `themes/` from the previous installation to the new installation.
. Copy `providers/` and `themes/` from the previous installation to the new installation.
. Copy all files except `cache-ispn.xml` from `conf/` from the previous installation to the new installation.
. If you modified `cache-ispn.xml` or created a custom cache configuration file:
.. Re-apply your changes based on the `cache-ispn.xml` file shipped with the new installation, and place them in the new installation.
.. Review the latest {project_name} configuration options for cache sizes and transport stacks if they can be used instead of your modifications as they provide better documentation, additional validations and functionality, and a simpler upgrade experience.