|
1 | 1 | # Release Process
|
2 | 2 |
|
3 |
| -Releases are mostly automated using |
4 |
| -[release-it](https://github.com/release-it/release-it/) and |
5 |
| -[lerna-changelog](https://github.com/lerna/lerna-changelog/). |
| 3 | +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 to prepare the release once the PR is merged. |
6 | 4 |
|
7 | 5 | ## Preparation
|
8 | 6 |
|
9 |
| -Since the majority of the actual release process is automated, the primary |
10 |
| -remaining task prior to releasing is confirming that all pull requests that |
11 |
| -have been merged since the last release have been labeled with the appropriate |
12 |
| -`lerna-changelog` labels and the titles have been updated to ensure they |
13 |
| -represent something that would make sense to our users. Some great information |
14 |
| -on why this is important can be found at |
15 |
| -[keepachangelog.com](https://keepachangelog.com/en/1.0.0/), but the overall |
16 |
| -guiding principle here is that changelogs are for humans, not machines. |
17 |
| - |
18 |
| -When reviewing merged PR's the labels to be used are: |
19 |
| - |
20 |
| -* breaking - Used when the PR is considered a breaking change. |
21 |
| -* enhancement - Used when the PR adds a new feature or enhancement. |
22 |
| -* bug - Used when the PR fixes a bug included in a previous release. |
23 |
| -* documentation - Used when the PR adds or updates documentation. |
24 |
| -* internal - Used for internal changes that still require a mention in the |
25 |
| - changelog/release notes. |
26 |
| - |
27 |
| -## Release |
| 7 | +Since the majority of the actual release process is automated, the remaining tasks before releasing are: |
28 | 8 |
|
29 |
| -Once the prep work is completed, the actual release is straight forward: |
| 9 | +- correctly labeling **all** pull requests that have been merged since the last release |
| 10 | +- updating pull request titles so they make sense to our users |
30 | 11 |
|
31 |
| -* First, ensure that you have installed your projects dependencies: |
32 |
| - |
33 |
| -```sh |
34 |
| -npm ci |
35 |
| -``` |
36 |
| - |
37 |
| -* Second, ensure that you have obtained a |
38 |
| - [GitHub personal access token][generate-token] with the `repo` scope (no |
39 |
| - other permissions are needed). Make sure the token is available as the |
40 |
| - `GITHUB_AUTH` environment variable. |
41 |
| - |
42 |
| - For instance: |
| 12 | +Some great information on why this is important can be found at [keepachangelog.com](https://keepachangelog.com/en/1.1.0/), but the overall |
| 13 | +guiding principle here is that changelogs are for humans, not machines. |
43 | 14 |
|
44 |
| - ```bash |
45 |
| - export GITHUB_AUTH=abc123def456 |
46 |
| - ``` |
| 15 | +When reviewing merged PR's the labels to be used are: |
47 | 16 |
|
48 |
| -[generate-token]: https://github.com/settings/tokens/new?scopes=repo&description=GITHUB_AUTH+env+variable |
| 17 | +- breaking - Used when the PR is considered a breaking change. |
| 18 | +- enhancement - Used when the PR adds a new feature or enhancement. |
| 19 | +- bug - Used when the PR fixes a bug included in a previous release. |
| 20 | +- documentation - Used when the PR adds or updates documentation. |
| 21 | +- internal - Internal changes or things that don't fit in any other category. |
49 | 22 |
|
50 |
| -* And last (but not least 😁) do your release. |
| 23 | +**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` |
51 | 24 |
|
52 |
| -```sh |
53 |
| -npx release-it |
54 |
| -``` |
| 25 | +## Release |
55 | 26 |
|
56 |
| -[release-it](https://github.com/release-it/release-it/) manages the actual |
57 |
| -release process. It will prompt you to to choose the version number after which |
58 |
| -you will have the chance to hand tweak the changelog to be used (for the |
59 |
| -`CHANGELOG.md` and GitHub release), then `release-it` continues on to tagging, |
60 |
| -pushing the tag and commits, etc. |
| 27 | +Once the prep work is completed, the actual release is straight forward: you just need to merge the open [Plan Release](https://github.com/rwjblue/codemod-cli/pulls?q=is%3Apr+is%3Aopen+%22Prepare+Release%22+in%3Atitle) PR |
0 commit comments