paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 40 Packages Projects Releases Wiki Activity

docs,workflows: updates and new branch name for emergency release flow

Browse Source 
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
This commit is contained in:
Patrik Oldsberg
2022-01-28 23:43:12 +01:00
parent 2b06ccadb3
commit 7fdd461135
2 changed files with 30 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/deploy_packages.yml
+1 -1
View File
@@ -3,7 +3,7 @@ name: Deploy Packages
on:
workflow_dispatch:
push:
branches: [master, release-*-patch]
branches: [master, patch/*]
jobs:
build:
docs/publishing.md
+29 -30
View File
@@ -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"
}
}
```