mirror of https://github.com/ctz/rustls
RELEASING.md: restructure, use github releases
This commit is contained in:
parent
7924f00a81
commit
4a9f375aac
52
RELEASING.md
52
RELEASING.md
|
@ -1,23 +1,25 @@
|
|||
# Making a rustls release
|
||||
## Before making a release
|
||||
|
||||
This is a checklist for steps to make before/after making a rustls release.
|
||||
|
||||
1. Attend to the README.md: this appears on crates.io for the release, and can't be edited after
|
||||
the fact.
|
||||
- Ensure the version has a good set of release notes. Move old release notes to OLDCHANGES.md
|
||||
if this is getting excessively long.
|
||||
- Write the version and date of the release.
|
||||
2. Run `cargo update` followed by `cargo outdated`, to check if we have any
|
||||
1. Run `cargo update` followed by `cargo outdated`, to check if we have any
|
||||
dependency updates which are not already automatically taken by their semver specs.
|
||||
- If we do, take them if possible with separate commits (but there should've been
|
||||
dependabot PRs submitted for these already.)
|
||||
3. Now run `cargo test --all-features` to ensure our tests continue to pass with the
|
||||
updated dependencies.
|
||||
4. Update `rustls/Cargo.toml` to set the correct version.
|
||||
5. Make a commit with the above changes, something like 'Prepare $VERSION'. This
|
||||
should not contain functional changes: just versions numbers, and markdown changes.
|
||||
6. Do a dry run: in `rustls/` check `cargo publish --dry-run`
|
||||
7. Push the above commit. Wait for CI to confirm it as green.
|
||||
- If we do, take them if possible. There should be dependabot PRs submitted for these already, but if
|
||||
not make separate commits for these and land those first.
|
||||
2. Update `rustls/Cargo.toml` to set the correct version.
|
||||
3. Make a commit with the new version number, something like 'Prepare $VERSION'. This
|
||||
should not contain functional changes: just version numbers, and perhaps markdown changes.
|
||||
4. Do a dry run: in `rustls/` check `cargo publish --dry-run`.
|
||||
- Do not use `--allow-dirty`; use a separate working tree if needed.
|
||||
5. Come up with text detailing headline changes for this release. General guidelines:
|
||||
* :green_heart: include any breaking changes.
|
||||
* :green_heart: include any major new headline features.
|
||||
* :green_heart: include any major, user-visible bug fixes.
|
||||
* :green_heart: include any new API deprecations.
|
||||
* :green_heart: emphasise contributions from outside the maintainer team.
|
||||
* :x: omit any internal build, process or test improvements.
|
||||
* :x: omit any minor or user-invisible bug fixes.
|
||||
* :x: omit any changes to dependency versions (unless these cause breaking changes).
|
||||
5. Open a PR with the above commit and include the release notes in the description.
|
||||
Wait for review and CI to confirm it as green.
|
||||
- Any red _should_ naturally block the release.
|
||||
- If rustc nightly is broken, this _may_ be acceptable if the reason is understood
|
||||
and does not point to a defect in rustls. eg, at the time of writing in releasing 0.20:
|
||||
|
@ -25,12 +27,16 @@ This is a checklist for steps to make before/after making a rustls release.
|
|||
- oss fuzz is broken: https://github.com/google/oss-fuzz/issues/6268
|
||||
(Both of these share the same root cause of LLVM13 breaking changes; which are
|
||||
unfortunately common when rustc nightly takes a new LLVM.)
|
||||
8. Tag the released version: `git tag -m '0.20.0' v/0.20.0`
|
||||
9. Push the tag: `git push --tags`
|
||||
10. Do the release: `cargo publish` when sat in `rustls/`.
|
||||
|
||||
## Post-release things
|
||||
## Making a release
|
||||
|
||||
- Update dependent crates (eg, hyper-rustls, rustls-native-certs, etc.)
|
||||
1. Tag the released version: eg. `git tag -m '0.20.0' v/0.20.0`
|
||||
2. Push the tag: eg. `git push origin v/0.20.0`
|
||||
3. Do the release: `cargo publish` when sat in `rustls/`.
|
||||
- Do not use `--allow-dirty`; use a separate working tree if needed.
|
||||
|
||||
## After making a release
|
||||
|
||||
1. Create a new GitHub release for that tag. Use "Generate release notes" (against the tag for the previous release)
|
||||
as a starting point for the release description. Then add the "headlines" produced earlier at the top.
|
||||
2. Update dependent crates (eg, hyper-rustls, rustls-native-certs, etc.) if this was a semver-incompatible release.
|
||||
|
|
Loading…
Reference in New Issue