mirror of
https://github.com/alacritty/alacritty.git
synced 2024-11-11 13:51:01 -05:00
Add documentation about patch releases
This commit is contained in:
parent
a669f12793
commit
2b2b2bfd2a
1 changed files with 28 additions and 17 deletions
|
@ -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
|
||||
|
||||
|
|
Loading…
Reference in a new issue