| 1 | # Release Process
|
| 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 prepare the release once the PR is merged.
|
| 4 |
|
| 5 | ## Preparation
|
| 6 |
|
| 7 | Since the majority of the actual release process is automated, the remaining tasks before releasing are:
|
| 8 |
|
| 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
|
| 11 |
|
| 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.
|
| 14 |
|
| 15 | When reviewing merged PR's the labels to be used are:
|
| 16 |
|
| 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.
|
| 22 |
|
| 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`
|
| 24 |
|
| 25 | ## Release
|
| 26 |
|
| 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/emberjs/ember-optional-features/pulls?q=is%3Apr+is%3Aopen+%22Prepare+Release%22+in%3Atitle) PR
|