rust/rustls
rust
/
rustls
mirror of https://github.com/ctz/rustls
1
0
Fork 0
Code Issues Releases Wiki Activity

docs: update RELEASING to mention running daily-tests 

Our daily tests CI job runs some additional tests that are too slow or
too flaky to be run for every merge requests. Before doing a release
it's a good idea to run this workflow manually to make sure there aren't
any lurking regressions that `cargo hack` or another test from this
workflow could catch pre-release.

This commit adds that guidance to `RELEASING.md` for future releases.
This commit is contained in:
Daniel McCarney 2024-02-29 14:02:12 -05:00
parent eb0791bc94
commit 408a42ae0e
1 changed files with 9 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
RELEASING.md
View File

@ -4,12 +4,16 @@
dependency updates which are not already automatically taken by their semver specs. dependency updates which are not already automatically taken by their semver specs.
- If we do, take them if possible. There should be dependabot PRs submitted for these already, but if - 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. not make separate commits for these and land those first.
2. Update `rustls/Cargo.toml` to set the correct version. 2. Run the daily-tests CI workflow to check if we have any unfixed regressions.
3. Make a commit with the new version number, something like 'Prepare $VERSION'. This You can run the workflow manually for the to-be-released branch by visiting
[the daily-tests workflow](https://github.com/rustls/rustls/actions/workflows/daily-tests.yml)
in your browser and selecting "Run workflow".
3. Update `rustls/Cargo.toml` to set the correct version.
4. 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. should not contain functional changes: just version numbers, and perhaps markdown changes.
4. Do a dry run: in `rustls/` check `cargo publish --dry-run`. 5. Do a dry run: in `rustls/` check `cargo publish --dry-run`.
- Do not use `--allow-dirty`; use a separate working tree if needed. - 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: 6. Come up with text detailing headline changes for this release. General guidelines:
* :green_heart: include any breaking changes. * :green_heart: include any breaking changes.
* :green_heart: include any major new headline features. * :green_heart: include any major new headline features.
* :green_heart: include any major, user-visible bug fixes. * :green_heart: include any major, user-visible bug fixes.
@ -18,7 +22,7 @@
* :x: omit any internal build, process or test improvements. * :x: omit any internal build, process or test improvements.
* :x: omit any minor or user-invisible bug fixes. * :x: omit any minor or user-invisible bug fixes.
* :x: omit any changes to dependency versions (unless these cause breaking changes). * :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. 7. 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. Wait for review and CI to confirm it as green.
- Any red _should_ naturally block the release. - Any red _should_ naturally block the release.
- If rustc nightly is broken, this _may_ be acceptable if the reason is understood - If rustc nightly is broken, this _may_ be acceptable if the reason is understood