PolytreeDE/alacritty
1
0
Fork 0
mirror of https://github.com/alacritty/alacritty.git synced 2024-11-18 13:55:23 -05:00
Code Releases Activity

Create only one branch per major release

Browse source 
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.
This commit is contained in:
Kirill Chibisov 2023-11-24 02:33:14 +04:00 committed by GitHub
parent 40160c5da1
commit b34a5e439a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
CONTRIBUTING.md
View file

@ -113,14 +113,14 @@ documentation comments.
Alacritty's release process aims to provide stable and well tested releases without having to hold Alacritty's release process aims to provide stable and well tested releases without having to hold
back new features during the testing period. 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 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 development versions, allowing us to keep the branches completely separate without merging releases
back into master. back into master.
The exact steps for an exemplary `0.2.0` release might look like this: 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` 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` 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` 4. The new commit in the branch is tagged as `v0.2.0-rc1`
5. The pre-release versions are published to crates.io 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: 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` 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 2. The `v0.2` branch is checked out
4. All bug fixes are cherry-picked from master into the `v0.2.3` branch 3. All bug fixes are cherry-picked from master into the `v0.2` branch
5. The version is bumped to `v0.2.3-rc1` and the changelog is updated to include all fixes 4. 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 5. 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 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` 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 and `-rcX` version suffix identical across the two crates. As soon as the new Alacritty stable