refresh release process

docs/configure/site/legacy-url-mappings.md

@@ -16,7 +16,7 @@ en/elasticsearch/reference/:
 ## Structure
 
 `stack anchor`
-:   Defines a reusable list of version strings for "stack" projects, e.g., [ '9.0+', '8.18', ... ].
+:   Defines a reusable list of version strings for "stack" projects, e.g., [ '8.18', ... ].
 
 `mappings`
 :   A YAML mapping where each key is a legacy documentation URL path (like `en/apm/agent/java/`), and each value is a mapping with:

docs/contribute/branching-strategy.md

@@ -46,9 +46,9 @@ After it has been established that a repository should publish from a version br
      * Otherwise, keeping it set to `main` is also an option since this is where the content is initially developed and merged. This is the default.
 4. In the assembler PR, add the `ci` label. After CI runs, confirm that the intended version branches are publishing to the link service. When links are being published as intended, they can be found at the following URL, where `repo` is your repo name and `branch` is your newly configured branch:
 
-  ```text
-  elastic-docs-link-index.s3.us-east-2.amazonaws.com/elastic/<repo>/<branch>/links.json
-  ```
+    ```text
+    elastic-docs-link-index.s3.us-east-2.amazonaws.com/elastic/<repo>/<branch>/links.json
+    ```
 5. Rerun the `validate-assembler` check on the PR.
 6. After checks pass and the docs engineering team approves, you can merge the PR.
 

docs/contribute/release-new-version.md

@@ -4,9 +4,15 @@ When a new version of the Elastic Stack (or another versioned product) is releas
 
 Follow these steps to release a new documentation version.
 
-:::::{stepper}   
+:::{tip}
+The docs-builder PR steps can be bundled into a single PR.
+:::
+
+:::::{stepper}
+
+::::{step} [docs-builder PR] Update `versions.yml`
 
-::::{step} Update `versions.yml`
+_This action can be performed by any member of the docs team. It's also [automated](https://github.com/elastic/docs-builder/actions/workflows/updatecli.yml) for many products._
 
 The `versions.yml` file defines the **base** (minimum) and **current** (latest) versions of each versioned product family.
 
@@ -22,11 +28,42 @@ versioning_systems:
 - Update the `current` version to reflect the newly released version.
 - Only update the `base` version if you're dropping support for an older version.
 
-Refer to [`versions.yml`](../configure/site/versions.md) for more information.
+Refer to [`versions.yml`](/configure/site/versions.md) for more information.
 
 ::::
 
-::::{step} (Optional) Update legacy URL mappings
+::::{step} [docs-builder PR] (Optional) Bump the version branch
+_This action can be performed by any member of the docs team._
+
+If you use the [tagged branching strategy](/contribute/branching-strategy.md), and your release corresponds with a new branch in the repository that holds your documentation, then you also need to bump the `current` and `next` branch in the docs configuration.
+
+This step is not always required, depending on your branching strategy. For example, if you only have branches for major versions of your product (e.g. 1 and 2), and you're already publishing your docs from the `1` branch, then you don't need to bump the version branch to release version 1.2 or 1.2.3 of your documentation.
+
+1. In `assembler.yml`, specifying the new `current` and `next` branches for your repository:
+
+    ```yml
+    your-product:
+    current: 1.1
+    next: 1.2
+    ```
+
+    Some people use `main` or `master` for their `next` branch. In this case, the `next` value doesn't need to be changed.
+
+2. Tag the PR with the `ci` label. After CI runs, confirm that the intended version branches are publishing to the link service. When links are being published as intended, they can be found at the following URL, where repo is your repo name and branch is your newly configured branch:
+
+    ```
+    elastic-docs-link-index.s3.us-east-2.amazonaws.com/elastic/<repo>/<branch>/links.json
+    ```
+
+3. Rerun the `validate-assembler` check on the PR.
+
+
+[Learn more about changing the published branch](/contribute/branching-strategy.md#how-to-change-the-published-branch).
+::::
+
+::::{step} [docs-builder PR] (Optional) Update legacy URL mappings
+
+_This action can be performed by any member of the docs team._
 
 If you're releasing a version older than the current `base`, or restoring support for a previously removed version, you may need to update the `legacy-url-mappings.yml` file.
 
@@ -35,21 +72,48 @@ This file maps legacy URL paths (like `en/elasticsearch/reference/`) to the list
 For example, to release the 8.19 version of the Elastic Stack, update the `stack` versions array to include the new version number:
 
 ```yml
-- stack: &stack [ '9.0+', '8.19', '8.18', '8.17', ... ]
+- stack: &stack [ '8.19', '8.18', '8.17', ... ]
 ```
 
+See [`legacy-url-mappings.yml`](../configure/site/legacy-url-mappings.md) for more information.
+
+::::
+
+::::{step} [docs-builder PR] Approve and merge the config change
+
+_This action must be performed by docs engineering._
+
+Merge the `versions.yml` changes and any assembler and legacy URL mapping changes.
+
+Optionally, invoke the [Synchronize version & config updates](https://github.com/elastic/docs-internal-workflows/actions/workflows/update-assembler-version.yml) action manually on `docs-internal-workflows`, which opens two configuration update PRs: `staging` and `prod`.
+
+This action also runs on a cron job, but you can trigger it manually if needed.
+
 :::{important}
-The first version in the `mappings` list is treated as the "current" version in documentation version dropdown.
+Do not merge the production PR until release day!
 :::
 
-See [`legacy-url-mappings.yml`](../configure/site/legacy-url-mappings.md) for more information.
+::::
+
+::::{step} After feature freeze: merge the config change to staging
+
+_This action must be performed by docs engineering._
+
+Merge [the `staging` configuration update PR](https://github.com/elastic/docs-internal-workflows/pulls).
+
+:::{important}
+Do not merge the production PR until release day!
+:::
 
 ::::
 
-::::{step} Release a new version of docs-builder
+::::{step} Release day: merge the config change to prod and release to production
+
+_This action must be performed by docs engineering. For most products, this change must be merged on release day._
 
-Version updates and content set additions require a release of docs-builder.
-Contact the Docs Eng team for assistance.
+1. Merge [the `prod` configuration update PR](https://github.com/elastic/docs-internal-workflows/pulls).
+2. Manually [invoke the release automation to production](https://github.com/elastic/docs-internal-workflows/actions/workflows/assembler-build.prod.yml).
+3. Let the requester or docs release coordinator know the docs have been updated.
 
 ::::
 
@@ -60,3 +124,4 @@ Cumulative documentation relies on version metadata through `applies_to` blocks,
 Check the built output to ensure `applies_to` changes are correctly rendering.
 
 ::::
+:::::