refresh release process

Author: shainaraskas

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/release-new-version.md

@@ -8,6 +8,8 @@ Follow these steps to release a new documentation version.
 
 ::::{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.
 
 Example:
@@ -28,28 +30,57 @@ Refer to [`versions.yml`](../configure/site/versions.md) for more information.
 
 ::::{step} (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.
 
 This file maps legacy URL paths (like `en/elasticsearch/reference/`) to the list of versions that exist at that path.
 
 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} Approve and merge the config change
+
+_This action must be performed by docs engineering._
+
+Merge the `versions.yml` changes and any 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.
 
 ::::