Skip to content

Commit

Permalink
npx create-release-plan-setup --update
Browse files Browse the repository at this point in the history
  • Loading branch information
NullVoxPopuli committed Dec 6, 2023
1 parent f1da49a commit d7311b1
Showing 1 changed file with 15 additions and 64 deletions.
79 changes: 15 additions & 64 deletions RELEASE.md
Original file line number Diff line number Diff line change
@@ -1,76 +1,27 @@
# Release Process

Releases are mostly automated using
[release-it](https://github.com/release-it/release-it/) and
[lerna-changelog](https://github.com/lerna/lerna-changelog/).
Releases in this repo are mostly automated using [release-plan](https://github.com/embroider-build/release-plan/). Once you label all your PRs correctly (see below) you will have an automatically generated PR that updates your CHANGELOG.md file and a `.release-plan.json` that is used prepare the release once the PR is merged.

## Preparation

Since the majority of the actual release process is automated, the primary
remaining task prior to releasing is confirming that all pull requests that
have been merged since the last release have been labeled with the appropriate
`lerna-changelog` labels and the titles have been updated to ensure they
represent something that would make sense to our users. Some great information
on why this is important can be found at
[keepachangelog.com](https://keepachangelog.com/en/1.0.0/), but the overall
guiding principle here is that changelogs are for humans, not machines.

When reviewing merged PR's the labels to be used are:

- breaking - Used when the PR is considered a breaking change.
- enhancement - Used when the PR adds a new feature or enhancement.
- bug - Used when the PR fixes a bug included in a previous release.
- documentation - Used when the PR adds or updates documentation.
- internal - Used for internal changes that still require a mention in the
changelog/release notes.

## Release

Once the prep work is completed, the actual release is straight forward:

- First, ensure that you have installed your projects dependencies:

```sh
pnpm install
```
Since the majority of the actual release process is automated, the remaining tasks before releasing are:

- Second, ensure that you have obtained a
[GitHub personal access token][generate-token] with the `repo` scope (no
other permissions are needed). Make sure the token is available as the
`GITHUB_AUTH` environment variable.
- correctly labeling **all** pull requests that have been merged since the last release
- updating pull request titles so they make sense to our users

For instance:

```bash
export GITHUB_AUTH=abc123def456
```

[generate-token]: https://github.com/settings/tokens/new?scopes=repo&description=GITHUB_AUTH+env+variable

- Test that the release will succeed. Make sure your `origin` git remote is using SSH (or you are authorized via your protocol of choice)

```sh
npx release-it --dry-run
```

If you've changed your origin from https to ssh, be sure to set the upstream:
Some great information on why this is important can be found at [keepachangelog.com](https://keepachangelog.com/en/1.1.0/), but the overall
guiding principle here is that changelogs are for humans, not machines.

```sh
git push --set-upstream origin main
```
When reviewing merged PR's the labels to be used are:

- And last (but not least 😁) do your release.
* breaking - Used when the PR is considered a breaking change.
* enhancement - Used when the PR adds a new feature or enhancement.
* bug - Used when the PR fixes a bug included in a previous release.
* documentation - Used when the PR adds or updates documentation.
* internal - Internal changes or things that don't fit in any other category.

```sh
npx release-it
```
**Note:** `release-plan` requires that **all** PRs are labeled. If a PR doesn't fit in a category it's fine to label it as `internal`

[release-it](https://github.com/release-it/release-it/) manages the actual
release process. It will prompt you to to choose the version number after which
you will have the chance to hand tweak the changelog to be used (for the
`CHANGELOG.md` and GitHub release), then `release-it` continues on to tagging,
pushing the tag and commits, etc.
## Release

If prompted for a username/password by `release-it`, the `GITHUB_AUTH` environment
variable was not detected. Enter your username, and use your personal access token
as the password, and the release should succeed.
Once the prep work is completed, the actual release is straight forward: you just need to merge the open [Plan Release](https://github.com/embroider-build/addon-blueprint/pulls?q=is%3Apr+is%3Aopen+%22Prepare+Release%22+in%3Atitle) PR

0 comments on commit d7311b1

Please sign in to comment.