PolytreeDE/alacritty
1
0
Fork 0
mirror of https://github.com/alacritty/alacritty.git synced 2024-11-25 14:05:41 -05:00
Code Releases Activity

Add documentation about patch releases

Browse source
This commit is contained in:
Christian Duerr 2020-05-27 16:39:44 +00:00 committed by GitHub
parent a669f12793
commit 2b2b2bfd2a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 28 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
CONTRIBUTING.md
View file

@ -116,23 +116,34 @@ and the final version are only comitted and tagged in this branch. The master br
development versions, allowing us to keep the branches completely separate without merging releases
back into master.
The exact steps for an exemplary `1.2.3` release might look like this:
1. Initially, the version on the latest master is `1.2.3-dev`
2. A new `v1.2.3` branch is created for the release
3. On master, the version is bumped to `1.2.4-dev`
4. In the branch, the version is bumped to `1.2.3-rc1`
5. The new commit in the branch is tagged as `v1.2.3-rc1`
6. A GitHub release is created for the `v1.2.3-rc1` tag
7. The changelog since the last release (stable or RC)
is added to the GitHub release description
8. Bug fixes are cherry-picked from master into the branch and steps 4-7
are repeated until no major issues are found in the release candidates
9. In the branch, the version is bumped to `1.2.3`
10. The new commit in the branch is tagged as `v1.2.3`
11. A GitHub release is created for the `v1.2.3` tag
12. The changelog since the last stable release (**not** RC)
is added to the GitHub release description
13. The `-dev` is stripped from previous changelog entries
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
3. On master, the version is bumped to `0.3.0-dev`
4. In the branch, the version is bumped to `0.2.0-rc1`
5. The new commit in the branch is tagged as `v0.2.0-rc1`
6. A GitHub release is created for the `v0.2.0-rc1` tag
7. The changelog since the last release (stable or RC) is added to the GitHub release description
8. Bug fixes are cherry-picked from master into the branch and steps 4-7 are repeated until no
major issues are found in the release candidates
9. In the branch, the version is bumped to `0.2.0`
10. The new commit in the branch is tagged as `v0.2.0`
11. A GitHub release is created for the `v0.2.0` tag
12. The changelog since the last stable release (**not** RC) is added to the GitHub release
description
13. The `-dev` is stripped from the `0.2.0-dev` changelog entries on master
On master and with new planned releases, only the minor version is bumped. This makes it possible to
create bug fix releases by incrementing the patch version of a previous minor release, without
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 5-12 of the regular release's example
7. The release's changelog is ported back to master, removing fixes from the `0.2.3` release
# Contact