diff options
| author | Kirill Chibisov <contact@kchibisov.com> | 2023-11-24 02:33:14 +0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-11-24 02:33:14 +0400 |
| commit | b34a5e439aae9750af8f8c8cc7b6799e1c51ab5a (patch) | |
| tree | 1bc9f6bd7a5cc27055ea3b0cdc680eb9eec372d3 | |
| parent | 40160c5da1fafeab3ccedc52efe2c135f1eab843 (diff) | |
| download | alacritty-b34a5e439aae9750af8f8c8cc7b6799e1c51ab5a.tar.gz alacritty-b34a5e439aae9750af8f8c8cc7b6799e1c51ab5a.zip | |
Create only one branch per major release
Having a separate branch for each release makes it harder to maintain
without an actual benefit, since every release from the major version
is linear, so creating branches doesn't make any sense.
They also collapse with the tag names leading to ambiguous refs.
| -rw-r--r-- | CONTRIBUTING.md | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 427b26a9..334a3e76 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -113,14 +113,14 @@ documentation comments. Alacritty's release process aims to provide stable and well tested releases without having to hold back new features during the testing period. -To achieve these goals, a new branch is created for every new release. Both the release candidates +To achieve these goals, a new branch is created for every major release. Both the release candidates and the final version are only committed and tagged in this branch. The master branch only tracks development versions, allowing us to keep the branches completely separate without merging releases back into master. The exact steps for an exemplary `0.2.0` release might look like this: 1. Initially, the version on the latest master is `0.2.0-dev` - 2. A new `v0.2.0` branch is created for the release + 2. A new `v0.2` branch is created for the release 3. In the branch, the version is bumped to `0.2.0-rc1` 4. The new commit in the branch is tagged as `v0.2.0-rc1` 5. The pre-release versions are published to crates.io @@ -143,11 +143,11 @@ having to adjust the next planned release's version number. The exact steps for an exemplary `0.2.3` release might look like this: 1. Initially, the version on the latest master is `0.3.0-dev` and the latest release was `0.2.2` - 2. A new `v0.2.3` branch is forked from the `v0.2.2` branch - 4. All bug fixes are cherry-picked from master into the `v0.2.3` branch - 5. The version is bumped to `v0.2.3-rc1` and the changelog is updated to include all fixes - 6. Follow Steps 4-13 of the regular release's example - 7. The release's changelog is ported back to master, removing fixes from the `0.2.3` release + 2. The `v0.2` branch is checked out + 3. All bug fixes are cherry-picked from master into the `v0.2` branch + 4. The version is bumped to `v0.2.3-rc1` and the changelog is updated to include all fixes + 5. Follow Steps 4-13 of the regular release's example + 6. The release's changelog is ported back to master, removing fixes from the `0.2.3` release The `alacritty_terminal` crate is released in synchronization with `alacritty`, keeping the `-dev` and `-rcX` version suffix identical across the two crates. As soon as the new Alacritty stable |