diff options
| author | Christian Duerr <contact@christianduerr.com> | 2022-02-10 12:09:23 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-02-10 11:09:23 +0000 |
| commit | eefce4e9af9bf64aeb2c63bb7171377e47c8c98a (patch) | |
| tree | 24420ee4cd1679de896f01a33c73c57473ce538c /CONTRIBUTING.md | |
| parent | d1608dd03e330e2c53ebf451b6f60d027a30091d (diff) | |
Add note about publishing RCs to crates.io
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.
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 21 |
1 files changed, 11 insertions, 10 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4994597f..fe104800 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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` |