docs-reorg: reorganize 'Releases' section - skip v13

Author: fenekku

docs/develop/architecture/communities.md

@@ -6,7 +6,7 @@ This guide is intended for maintainers and developers of InvenioRDM itself.
 
 **Scope**
 
-The guide provides a high-level architectural overview of the communities 
+The guide provides a high-level architectural overview of the communities
 module for InvenioRDM.
 
 ## Community visibility
@@ -16,7 +16,7 @@ Communities visibility can be set to either:
 - *public* - any user can see the community
 - *restricted* - only community members can see the community
 
-![Create a community](../../releases/versions/v9.0/community-create.png)
+![Create a community](../../releases/v9/imgs/community-create.png)
 
 Both public and restricted communities can contain restricted records, and thus
 not all records in a public community may be visible to everyone. A restricted
@@ -30,7 +30,7 @@ communities to ensure a consistent user experience across all communities.
 A community role translates into a set of permissions. The roles are
 configurable to ensure that they can be tailored to the needs of an instance,
 as well as allow for customizations. For example, one instance may use
-"curator" and another may use "editor" as a role because it suits 
+"curator" and another may use "editor" as a role because it suits
 their use case better.
 
 By default the following community roles are defined:

docs/index.md

@@ -7,4 +7,4 @@ template: frontpage.html
 
 !!! tip "August 1st, 2024: InvenioRDM v12.0 Long-term support available! ✨"
 
-    🚀 Read the full [release notes](releases/versions/version-v12.0.0.md).
+    🚀 Read the full [release notes](releases/v12/version-v12.0.0.md).

docs/releases/index.md

@@ -7,11 +7,11 @@ We aim to have a quarterly release cycle, to push out new features as fast as po
 
 Only releases designated **Long-Term Support (LTS)** releases are supported for production services.
 
-Our aim is to ensure that users of InvenioRDM follows our latest releases by making the upgrade process a seamless experience.
+Our aim is to ensure that users of InvenioRDM follow our latest releases by making the upgrade process a seamless experience.
 
 
 ## Policies
 
 - [Maintenance policy](maintenance-policy.md)
 - [Security policy](security-policy.md)
-- [Upgrade policy](upgrading/index.md)
+- [Upgrade policy](upgrade-policy.md)

docs/releases/upgrading/migrate-docker-images.md renamed to docs/releases/migrate-docker-images.md

@@ -10,7 +10,7 @@ The base Docker images for InvenioRDM v9.x and v10.x were hosted on Docker Hub,
 
 Depending on what will happen, building the Docker images on InvenioRDM v9/v10 with the commands `invenio-cli containers ` might fail.
 
-With InvenioRDM v11, released on January 26, 2023, we have migrated the Docker images to the CERN registry, see [here the release notes](../versions/version-v11.0.0.md#deployment). This was done for a couple of reasons:
+With InvenioRDM v11, released on January 26, 2023, we have migrated the Docker images to the CERN registry, see [here the release notes](v11/version-v11.0.0.md#deployment). This was done for a couple of reasons:
 
 1. Avoid [Docker Hub rate limits](https://www.docker.com/increase-rate-limits/).
 2. Take advantage of the automatic security scan provided by the CERN registry.
@@ -75,7 +75,7 @@ There are two possible ways to migrate:
     + FROM registry.cern.ch/inveniosoftware/almalinux:1
     ```
 
-    In this last case of AlmaLinux, make sure that you are running Python 3.9, which is the Python version that comes with the `almalinux` image. You should follow the [v11 Python version change](./upgrade-v11.0.md#python-version-change) instructions to make sure that you are taking the necessary steps.
+    In this last case of AlmaLinux, make sure that you are running Python 3.9, which is the Python version that comes with the `almalinux` image. You should follow the [v11 Python version change](v11/upgrade-v11.0.md#python-version-change) instructions to make sure that you are taking the necessary steps.
 
 !!! warning "Test!"
     The change of the base Docker image can lead to unexpected issues. We recommend testing your instance extensively in a test environment, before deployment to production.

docs/releases/upgrading/index.md renamed to docs/releases/upgrade-policy.md

@@ -52,19 +52,19 @@ The deposit form now has a new protection widget that allows you to deposit reco
 
 Below are some examples of how this now looks in the deposit form:
 
-![](v1.0/1_access_control_examples.png)
+![](imgs/1_access_control_examples.png)
 
 **Restricted records and files**
 
 Restricted records and files are only visible for the owner (the user who deposited the material). This means that e.g. a restricted record will not show up in the search results of other users.
 
 User without access (no files and no edit button visible):
 
-![](v1.0/2_access_control_restricted_files.png)
+![](imgs/2_access_control_restricted_files.png)
 
 User with access (files and edit button visible):
 
-![](v1.0/3_access_control_owner.png)
+![](imgs/3_access_control_owner.png)
 
 Note, that the message "Sorry, the files are restricted!" is a temporary message, until we have a solution for the access badge (see next section).
 
@@ -74,11 +74,11 @@ We have temporarily removed the access status badge (see before/after screenshot
 
 Before:
 
-![](v1.0/4_access_badge_before.png)
+![](imgs/4_access_badge_before.png)
 
 After:
 
-![](v1.0/5_access_badge_after.png)
+![](imgs/5_access_badge_after.png)
 
 **Limitation: Embargo feature**
 
@@ -118,11 +118,11 @@ We have fixed a large number of small styling and consistentcy issues. Still som
 
 The list uploads page now has a nice greeting for first time users:
 
-![](v1.0/6_list_uploads_empty.png)
+![](imgs/6_list_uploads_empty.png)
 
 Also, the overall styling of the page was improved:
 
-![](v1.0/7_list_uploads_styling.png)
+![](imgs/7_list_uploads_styling.png)
 
 **Search guide**
 

docs/releases/upgrading/upgrade-v13.0.md

@@ -26,13 +26,13 @@ You can also extend the default components or implement your owns. To get more i
 
 Below, an example of the upload form with custom fields related to software. You can test them out in the [demo site upload form](https://inveniordm.web.cern.ch/uploads/new).
 
-![](img/../v10.0/custom_fields.png)
+![](imgs/custom_fields.png)
 
 #### Community settings page
 
 Custom fields will be displayed at the bottom of the community's settings page.
 
-![](img/../v10.0/custom_fields_communities.png)
+![](imgs/custom_fields_communities.png)
 
 When a community field is required, it will be also displayed in the form to [create a new community](https://inveniordm.web.cern.ch/communities/new).
 
@@ -42,7 +42,7 @@ The new administration panel provides a modern, clean and easy to use interface.
 
 This release comes with the first new OAI-PMH administration view, which allows to manage or create OAI-PMH sets.
 
-![](img/../v10.0/backoffice_oai_sets.png)
+![](imgs/backoffice_oai_sets.png)
 
 Some OAI-PMH sets are automatically created when a new community is added. These system created sets are blocked from edition in the administration view to preserve the data sets integrity.
 
@@ -60,15 +60,15 @@ With the [change of license](https://www.elastic.co/pricing/faq/licensing) of El
 
 While Elasticsearch v7 is still supported, Elasticsearch v6 support has been removed. However, Elasticsearch support will be removed in a future version of InvenioRDM.
 
-We recommend migrating directly to OpenSearch v2, OpenSearch v1 [end of life](https://endoflife.date/opensearch) is rapidly approaching. See the [upgrade guide](../upgrading/upgrade-v10.0.md) for more information.
+We recommend migrating directly to OpenSearch v2, OpenSearch v1 [end of life](https://endoflife.date/opensearch) is rapidly approaching. See the [upgrade guide](./upgrade-v10.0.md) for more information.
 
 You can read more on how to setup an OpenSearch cluster in the [official documentation](https://opensearch.org/docs/latest/opensearch/install/index/). [Invenio Helm Charts](https://github.com/inveniosoftware/helm-invenio/) have been updated adding support for OpenSearch, but the configuration will setup a demo cluster and it should **not be used in production**. OpenSearch provides [official Helm charts](https://opensearch.org/docs/latest/opensearch/install/helm/) suitable for production environments.
 
 ## Changes
 
 ### Breaking changes
 
-- Elasticsearch 6 support has been removed. If you are using InvenioRDM with Elasticsearch 6, you can migrate to Elasticsearch 7 or directly to OpenSearch. See the [upgrade guide](../upgrading/upgrade-v10.0.md) for more information.
+- Elasticsearch 6 support has been removed. If you are using InvenioRDM with Elasticsearch 6, you can migrate to Elasticsearch 7 or directly to OpenSearch. See the [upgrade guide](./upgrade-v10.0.md) for more information.
 - The configuration variable `INVENIO_SEARCH_ELASTIC_HOSTS` has been deprecated (but non-breaking) and it will be removed in the following releases. Please change its name to `INVENIO_SEARCH_HOSTS`. This variable is most probably also used in your deployment environments.
 - The following changes should not affect the majority of the users. We recommend to verify if any usage can be found in customisations or modules:
     - In [Invenio-Indexer](https://github.com/inveniosoftware/invenio-indexer), the param `es_bulk_kwargs` in the class `RecordIndexer` has been renamed to `search_bulk_kwargs`. The method `record_to_index` and `schema_to_index` now return only the index and not a tuple with index and doc type. The configuration variable `INDEXER_DEFAULT_DOC_TYPE` is now removed.
@@ -81,13 +81,13 @@ You can read more on how to setup an OpenSearch cluster in the [official documen
 
 **Strict search mappings**
 
-Search mappings have been made strict, which means that no unknown fields will be accepted. Before, no errors were being thrown. If you had custom record dumpers you might need to add custom fields and rebuild the indices. See the [upgrade guide](../upgrading/upgrade-v10.0.md) for more information.
+Search mappings have been made strict, which means that no unknown fields will be accepted. Before, no errors were being thrown. If you had custom record dumpers you might need to add custom fields and rebuild the indices. See the [upgrade guide](./upgrade-v10.0.md) for more information.
 
 **Deposit form publish modal warning text customization**
 
 The warning text shown in the modal during the publish/submit-for-review action can now be extended via the `APP_RDM_DEPOSIT_FORM_PUBLISH_MODAL_EXTRA` config variable. You can pass text or html there and the result will look like the following:
 
-![Customize publish modal warning text](./v10.0/publish_modal_text_customize.png)
+![Customize publish modal warning text](imgs/publish_modal_text_customize.png)
 
 ## Deprecations
 
@@ -99,7 +99,7 @@ With this release, communities custom fields are not displayed in the community
 
 ## Upgrading to v10.0
 
-We support upgrading from v9.1 to v10 Please see the [upgrade notice](../upgrading/upgrade-v10.0.md).
+We support upgrading from v9.1 to v10 Please see the [upgrade notice](./upgrade-v10.0.md).
 
 ## Maintenance policy
 

docs/releases/versions/v1.0/1_access_control_examples.png renamed to docs/releases/v1/imgs/1_access_control_examples.png

@@ -167,7 +167,7 @@ Support for Elasticsearch v7 is deprecated and it will be removed in a future re
 
 ## Upgrading to v11.0
 
-We support upgrading from v10 to v11. Please see the [upgrade notice](../upgrading/upgrade-v11.0.md).
+We support upgrading from v10 to v11. Please see the [upgrade notice](./upgrade-v11.0.md).
 
 ## Maintenance policy