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 note about publishing RCs to crates.io

Browse source 
We've been testing out the pre-release feature of crates.io and there
haven't been any major issues. So this updates the documentation to
recommend publishing to crates.io even before the official release.
This commit is contained in:
Christian Duerr 2022-02-10 12:09:23 +01:00 committed by GitHub
parent d1608dd03e
commit eefce4e9af
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
CONTRIBUTING.md
View file

@ -124,17 +124,18 @@ The exact steps for an exemplary `0.2.0` release might look like this:
2. A new `v0.2.0` 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. A GitHub release is created for the `v0.2.0-rc1` tag
6. The changelog since the last release (stable or RC) is added to the GitHub release description
7. On master, the version is bumped to `0.3.0-dev`
5. The pre-release versions are published to crates.io
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. On master, the version is bumped to `0.3.0-dev`
and the `-dev` suffix is removed from the `0.2.0-dev` changelog
8. Bug fixes are cherry-picked from master into the branch and steps 4-7 are repeated until no
9. Bug fixes are cherry-picked from master into the branch and steps 3-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. The new version is published to crates.io
12. A GitHub release is created for the `v0.2.0` tag
13. The changelog since the last stable release (**not** RC) is added to the GitHub release
10. In the branch, the version is bumped to `0.2.0`
11. The new commit in the branch is tagged as `v0.2.0`
12. The new version is published to crates.io
13. A GitHub release is created for the `v0.2.0` tag
14. The changelog since the last stable release (**not** RC) is added to the GitHub release
description
On master and with new planned releases, only the minor version is bumped. This makes it possible to
@ -146,7 +147,7 @@ The exact steps for an exemplary `0.2.3` release might look like this:
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
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
The `alacritty_terminal` crate is released in synchronization with `alacritty`, keeping the `-dev`