diff --git a/README.md b/README.md
index e45b148..751ea99 100644
--- a/README.md
+++ b/README.md
@@ -263,152 +263,7 @@ to fix it up.
### Superseding Maven releases
-If you want to use Incrementals _instead_ of MRP,
-you can override `changelist.format` in your project (the default value is `-rc%d.%s`).
-
-For a regular component whose version number is not intrinsically meaningful:
-
-```diff
---- a/.mvn/extensions.xml
-+++ b/.mvn/extensions.xml
-@@ -2,6 +2,6 @@
-
- io.jenkins.tools.incrementals
- git-changelist-maven-extension
-- 1.0-beta-7
-+ 1.1
-
-
---- a/.mvn/maven.config
-+++ b/.mvn/maven.config
-@@ -1,2 +1,3 @@
- -Pconsume-incrementals
- -Pmight-produce-incrementals
-+-Dchangelist.format=%d.v%s
---- a/pom.xml
-+++ b/pom.xml
-@@ -7,7 +7,7 @@
-- ${revision}${changelist}
-+ ${changelist}
- hpi
-@@ -26,8 +26,7 @@
-
-- 1.23
-- -SNAPSHOT
-+ 999999-SNAPSHOT
- 2.176.4
- 8
-
-```
-
-Here a CI/release build (`-Dset.changelist` specified) will be of the form `123.vabcdef456789`.
-A snapshot build will be `999999-SNAPSHOT`: arbitrary but treated as a snapshot by Maven and newer than any release.
-
-For a component whose version number ought to reflect a release version of some wrapped component:
-
-```diff
---- a/.mvn/extensions.xml
-+++ b/.mvn/extensions.xml
-@@ -2,6 +2,6 @@
-
- io.jenkins.tools.incrementals
- git-changelist-maven-extension
-- 1.0-beta-7
-+ 1.1
-
-
---- a/.mvn/maven.config
-+++ b/.mvn/maven.config
-@@ -1,2 +1,3 @@
- -Pconsume-incrementals
- -Pmight-produce-incrementals
-+-Dchangelist.format=%d.v%s
---- a/pom.xml
-+++ b/pom.xml
-@@ -10,12 +10,12 @@
- some-library-wrapper
-- ${revision}${changelist}
-+ ${revision}-${changelist}
- hpi
-
-- 4.0.0-1.3
-- -SNAPSHOT
-+ 4.0.0
-+ 999999-SNAPSHOT
- 2.176.4
- 8
-```
-
-Here the version numbers will look like `4.0.0-123.vabcdef456789` or `4.0.0-999999-SNAPSHOT`, respectively.
-When you pick up a new third-party component like `4.0.1`, your version numbers will match;
-to refer to the third-party component, just use
-
-```xml
-${revision}
-```
-
-Since inadvertently running MRP on such a project would result in a mess,
-it is best to explicitly prevent that.
-This is done automatically by the plugin and general component parent POMs
-when you define the `changelist.format` property.
-
-#### Automatic deployment
-
-If you have configured `changelist.format` as above,
-using [JEP-229](https://jenkins.io/jep/229) you can then set up automatic publishing of artifacts.
-
-First, file a patch to your component’s entry(ies) in [RPU](https://github.com/jenkins-infra/repository-permissions-updater/tree/master/permissions) to add
-
-```yaml
-cd:
- enabled: true
-```
-
-Once that has been merged, start checking `https://github.com/jenkinsci/your-plugin/settings/secrets/actions`
-and you should soon see `MAVEN_TOKEN` and `MAVEN_USERNAME` appear under **Repository secrets**.
-
-Next, if you already have Release Drafter configured,
-remove any `tag-template` override in `.github/release-drafter.yml`,
-and delete `.github/workflows/release-drafter.yml` if using GitHub Actions (or remove the app from the repo otherwise).
-If you have not yet configured Release Drafter, just create `.github/release-drafter.yml` containing only
-
-```yaml
-_extends: .github
-```
-
-If you have a `.github/dependabot.yml`, it is a good idea to add
-
-```yaml
-- package-ecosystem: github-actions
- directory: /
- schedule:
- interval: daily
-```
-
-Finally create `.github/workflows/cd.yaml` as a copy of [this template](https://github.com/jenkinsci/.github/blob/master/workflow-templates/cd.yaml).
-
-Now whenever Jenkins reports a successful build of your default branch,
-and at least one pull request had a label indicating it was of interest to users (e.g. `enhancement` rather than `chore`),
-your component will be released to Artifactory and release notes published in GitHub.
-You do not need any special credentials or local checkout;
-just merge pull requests with suitable titles and [labels](https://github.com/jenkinsci/.github/blob/7baf6188c5dbe8f872bd7f4e13e1aaeee0b2e279/.github/release-drafter.yml#L9-L49).
-
-You can also trigger a deployment explicitly, if the current commit has a passing check from Jenkins.
-Visit `https://github.com/jenkinsci/your-plugin/actions?query=workflow%3Acd` and click **Run workflow**.
-If you prefer to only deploy explicitly, not on every push, just comment out the `check_run` section above.
-
-(Do not be alarmed to see numerous failed `cd` workflows besides the passing ones that actually deployed:
-every check posted other than the top-level `Jenkins` check triggers a workflow which should quickly fail.)
-
-As a fallback, you can also release manually if you have
-[personal deployment credentials](https://github.com/jenkins-infra/repository-permissions-updater).
-To cut a release:
-
-```bash
-git checkout master
-git pull --ff-only
-mvn -Dset.changelist -DaltDeploymentRepository=maven.jenkins-ci.org::default::https://repo.jenkins-ci.org/releases/ clean deploy
-```
+See [Setting up automated plugin release](https://www.jenkins.io/redirect/continuous-delivery-of-plugins)
## Usage in other POMs