|
1 | | -# Release |
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/). |
| 1 | +# Release Process |
6 | 2 |
|
| 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. |
7 | 4 |
|
8 | 5 | ## Preparation |
9 | 6 |
|
10 | | -Since the majority of the actual release process is automated, the primary |
11 | | -remaining task prior to releasing is confirming that all pull requests that |
12 | | -have been merged since the last release have been labeled with the appropriate |
13 | | -`lerna-changelog` labels and the titles have been updated to ensure they |
14 | | -represent something that would make sense to our users. Some great information |
15 | | -on why this is important can be found at |
16 | | -[keepachangelog.com](https://keepachangelog.com/en/1.0.0/), but the overall |
17 | | -guiding principles here is that changelogs are for humans, not machines. |
18 | | - |
19 | | -When reviewing merged PR's the labels to be used are: |
20 | | - |
21 | | -* breaking - Used when the PR is considered a breaking change. |
22 | | -* enhancement - Used when the PR adds a new feature or enhancement. |
23 | | -* bug - Used when the PR fixes a bug included in a previous release. |
24 | | -* documentation - Used when the PR adds or updates documentation. |
25 | | -* internal - Used for internal changes that still require a mention in the |
26 | | - changelog/release notes. |
27 | | - |
28 | | - |
29 | | -## Release |
| 7 | +Since the majority of the actual release process is automated, the remaining tasks before releasing are: |
30 | 8 |
|
31 | | -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 |
32 | 11 |
|
33 | | -* First ensure that you have `release-it` installed globally, generally done by |
34 | | - using one of the following commands: |
| 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. |
35 | 14 |
|
36 | | -``` |
37 | | -# using https://volta.sh |
38 | | -volta install release-it |
39 | | -
|
40 | | -# using Yarn |
41 | | -yarn global add release-it |
42 | | -
|
43 | | -# using npm |
44 | | -npm install --global release-it |
45 | | -``` |
46 | | - |
47 | | -* Second, ensure that you have installed your projects dependencies: |
48 | | - |
49 | | -``` |
50 | | -# using yarn |
51 | | -yarn install |
| 15 | +When reviewing merged PR's the labels to be used are: |
52 | 16 |
|
53 | | -# using npm |
54 | | -npm install |
55 | | -``` |
| 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. |
56 | 22 |
|
57 | | -* 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` |
58 | 24 |
|
59 | | -``` |
60 | | -release-it |
61 | | -``` |
| 25 | +## Release |
62 | 26 |
|
63 | | -[release-it](https://github.com/release-it/release-it/) manages the actual |
64 | | -release process. It will prompt you through the process of choosing the version |
65 | | -number, tagging, 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/babel/ember-cli-babel/pulls?q=is%3Apr+is%3Aopen+%22Prepare+Release%22+in%3Atitle) PR |
0 commit comments