Merge pull request #8883 from backstage/mob/prerelease
Prepare for prerelease flow and introduce documentation and tooling for emergency releases
This commit is contained in:
Patrik Oldsberg
@@ -1,58 +0,0 @@
|
||||
---
|
||||
id: publishing
|
||||
title: Publishing
|
||||
description: Documentation on Publishing npm packages
|
||||
---
|
||||
|
||||
## npm
|
||||
|
||||
npm packages are published through CI/CD in the
|
||||
[`.github/workflows/master.yml`](https://github.com/backstage/backstage/blob/master/.github/workflows/master.yml)
|
||||
workflow. Every commit that is merged to master will be checked for new versions
|
||||
of all public packages, and any new versions will automatically be published to
|
||||
npm.
|
||||
|
||||
### Creating a new release
|
||||
|
||||
Version bumps are made through release PRs. To create a new release, checkout
|
||||
out a new branch that you will use for the release, e.g.
|
||||
|
||||
```sh
|
||||
$ git checkout -b new-release
|
||||
```
|
||||
|
||||
First bump the `CHANGELOG.md` in the root of the repo and commit. You bump it by
|
||||
adding a header for the new version just below the `## Next Release` one.
|
||||
|
||||
Then, from the root of the repo, run
|
||||
|
||||
```sh
|
||||
$ yarn release
|
||||
```
|
||||
|
||||
This will bring up the lerna release CLI where you choose what type of version
|
||||
bump you want to make, (major/minor/patch/prerelease). The CLI will take you
|
||||
through choosing a version, previewing all changes, and then approving the
|
||||
release. Once the release is approved, a new commit is created that you can
|
||||
submit as a PR. Push the branch to GitHub:
|
||||
|
||||
```sh
|
||||
$ git push origin -u new-release
|
||||
```
|
||||
|
||||
And then create a PR. Once the PR is approved and merged into master, the master
|
||||
build will publish new versions of all bumped packages.
|
||||
|
||||
### Include new changes in existing release PR
|
||||
|
||||
If you want to include some last minute changes to an existing release PR,
|
||||
follow these instructions:
|
||||
|
||||
```sh
|
||||
$ git checkout master
|
||||
$ git pull
|
||||
$ git checkout new-release
|
||||
$ git reset --hard master
|
||||
$ yarn release
|
||||
$ git push --force
|
||||
```
|
||||
@@ -0,0 +1,72 @@
|
||||
<!-- This is intentionally left out of the microsite, since it only applies to the main repo -->
|
||||
|
||||
## npm
|
||||
|
||||
npm packages are published through CI/CD in the
|
||||
[`.github/workflows/master.yml`](https://github.com/backstage/backstage/blob/master/.github/workflows/master.yml)
|
||||
workflow. Every commit that is merged to master will be checked for new versions
|
||||
of all public packages, and any new versions will automatically be published to
|
||||
npm.
|
||||
|
||||
### Creating a new release
|
||||
|
||||
Releases are handled by changesets and trigger whenever the "Version Packages"
|
||||
PR is merged. This is typically done every Thursday around noon CET.
|
||||
|
||||
## Emergency Release Process
|
||||
|
||||
**This emergency release process is intended only for the Backstage
|
||||
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.
|
||||
|
||||
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`:
|
||||
|
||||
- [ ] Identify the release that needs to be patched, in this case we're fixing a
|
||||
broken release, so it would be the most recent one, `2048-01-01`. In the
|
||||
event of a backported security fix, the release that has the last
|
||||
published version of each major version of the package should be the one
|
||||
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`.
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
- [ ] With the `release-2048-01-01-patch` 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
|
||||
```
|
||||
|
||||
- [ ] Apply fixes and create a new patch changeset for the affected package,
|
||||
then commit these changes.
|
||||
- [ ] 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.
|
||||
- [ ] Make sure the same fix is applied in master before the next release, and
|
||||
create an appropriate changeset for that as well. In the changeset towards
|
||||
master you should refer back to all patch releases that also received the
|
||||
same fix. Also be sure to update `.changeset/patched.json` in the same PR
|
||||
to make sure that future releases of the packages are bumped accordingly:
|
||||
|
||||
```json
|
||||
{
|
||||
"currentReleaseVersion": {
|
||||
"@backstage/plugin-foo": "1.5.1"
|
||||
}
|
||||
}
|
||||
```
|
||||
Reference in New Issue
Block a user