From d7311b16d85787e0afa3020b615fd6da4a4769ad Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Wed, 6 Dec 2023 10:59:40 -0500 Subject: [PATCH] npx create-release-plan-setup --update --- RELEASE.md | 79 +++++++++++------------------------------------------- 1 file changed, 15 insertions(+), 64 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index f5c65c1f..e4f92604 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -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