diff --git a/.github/workflows/deploy_packages.yml b/.github/workflows/deploy_packages.yml
index c21b7b7106..a1b5ab34a9 100644
--- a/.github/workflows/deploy_packages.yml
+++ b/.github/workflows/deploy_packages.yml
@@ -3,7 +3,7 @@ name: Deploy Packages
 on:
   workflow_dispatch:
   push:
-    branches: [master, release-*-patch]
+    branches: [master, patch/*]
 
 jobs:
   build:
diff --git a/docs/publishing.md b/docs/publishing.md
index ed83bddbbc..2951f7d30b 100644
--- a/docs/publishing.md
+++ b/docs/publishing.md
@@ -19,61 +19,60 @@ PR is merged. This is typically done every Thursday around noon CET.
 maintainers.**
 
 For this example we will be using the `@backstage/plugin-foo` package as an
-example and assume that it is currently version `1.5.0` in the master branch.
+example and assume that it is currently version `6.5.0` in the master branch.
 
-In the event of a severe bug being introduced in version `1.5.0` of the
-`@backstage/plugin-foo` released in the `2048-01-01` release, the following
-process is used to release an emergency fix as `1.5.1`:
+In the event of a severe bug being introduced in version `6.5.0` of the
+`@backstage/plugin-foo` released in the `v1.18.0` Backstage release, the following
+process is used to release an emergency fix as version `6.5.1` in the patch release `v1.18.1`:
 
 - [ ] Identify the release or releases that need to be patched. We should always
-      patch the most recent main-line release if needed, which in this example
-      would be `2048-01-01`. The fix may also need backporting to older major
+      patch the most recent major or minor main-line release if needed, which in this example
+      would be `v1.18.0`. The fix may also need backporting to older major
       versions, in which case we will want to patch the main-line release just
       before the one that bumped the package to each new major version.
 - [ ] Repeat the following steps for each release that needs to be patched:
 
   - [ ] Make sure a patch branch exists for the release that is being patched.
         If a patch already exists, reuse the existing branch. The branch **must
-        always** be named exactly `release-<release>-patch`.
+        always** be named exactly `patch/<release>`.
 
     ```bash
-    git checkout release-2048-01-01
-    git checkout -b release-2048-01-01-patch
-    git push --set-upstream origin release-2048-01-01-patch
+    git checkout v1.18.0
+    git checkout -b patch/v1.18.0
+    git push --set-upstream origin patch/v1.18.0
     ```
 
-  - [ ] With the `release-2048-01-01-patch` branch as a base, create a new
+  - [ ] With the `patch/v1.18.0` branch as a base, create a new
         branch for your fix. This branch can be named anything, but the
         following naming pattern may be suitable:
 
     ```bash
-    git checkout -b ${USER}/release-2048-01-01-emergency-fix
+    git checkout -b ${USER}/plugin-foo-v1.18.0-fix
     ```
 
-  - [ ] Create a single commit that applies fixes and creates a new patch
-        changeset for the affected package.
-  - [ ] Run `yarn release` in the root of the repo in order to convert your
-        changeset into package version bumps and changelog entries. Commit these
-        changes as a second `"Generated release"` commit.
-  - [ ] Create PR towards the base branch (`release-2048-01-01-patch`)
-        containing the two commits.
-  - [ ] Review/Merge the PR into `release-2048-01-01-patch`. This will
-        automatically trigger a release.
+  - [ ] Create a single commit that applies fix, nothing else.
+  - [ ] Create a changeset for the affected package(s), then run `yarn release` in the root
+        of the repo in order to convert your changeset into package version bumps and changelog entries.
+        Commit these changes as a second `"Generated release"` commit.
+  - [ ] Create PR towards the base branch (`patch/v1.18.0`) containing the two commits.
+  - [ ] Review/Merge the PR into `patch/v1.18.0`. This will automatically trigger a release.
 
-- [ ] Once fixes have been created for each release, the fix should be applied
-      to the master branch as well. Create a PR that contains the following:
+- [ ] Look up the new version of our package in the patch PR as well as the new release
+      version, these can be found in the package `package.json` and the root `package.json`, and
+      will in this case be `6.5.1` and `v1.18.1`. You will need these versions later.
+- [ ] Make sure you have the latest versions of the patch branch fetched, after merging the PR: `git fetch`.
+- [ ] Once fixes have been created for each release, the fix should be applied to the
+      master branch as well. Create a PR that contains the following:
 
-  - [ ] The fix.
-  - [ ] A changeset with the message "Apply fix from the x.y.z patch release",
-        in this case `1.5.1`. You can find the version in your patch PR for the
-        most recent release.
-  - [ ] An entry in `.changeset/patched.json` that sets the current release to
-        that same version:
+  - [ ] The fix, which you can likely cherry-pick from your patch branch: `git cherry-pick origin/patch/v1.18.0^`
+  - [ ] An updated `CHANGELOG.md` of all patched patches from the tip of the patch branch, which you can get using `git checkout origin/patch/v1.18.0 -- plugins/foo/CHANGELOG.md`.
+  - [ ] A changeset with the message "Applied the fix from version `6.5.1` of this package, which is part of the `v1.18.1` release of Backstage.",
+  - [ ] An entry in `.changeset/patched.json` that sets the current release version to `6.5.1`:
 
     ```json
     {
       "currentReleaseVersion": {
-        "@backstage/plugin-foo": "1.5.1"
+        "@backstage/plugin-foo": "6.5.1"
       }
     }
     ```