mirrors/arti.git/doc/dev/Release.md, branch arti-v1.1.10mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.102023-10-04T14:57:04ZUpdate changed_crates and Release.md to robustify release process2023-10-04T14:57:04ZNick Mathewsonnickm@torproject.org2023-10-04T14:52:32Zurn:sha1:5de0e614fee34ecfeda761414a8600e6f5fb71dd
In particular, this change should help avoid the kind of problem we
ran into as #1054 and fixed with 00e4405943498754, where a crate
changed only in which versions of our crates it depended upon,
and we didn't notice that we had to update its version too.
This commit also fixes a couple of minor issues in the
`changed_crates` script, and gives it a verbose mode.
Script to bump patchlevel without touching other crates2023-08-01T16:57:58ZNick Mathewsonnickm@torproject.org2023-08-01T16:57:58Zurn:sha1:b71b04eb849b693d17c74a82af62a63d9ac823e0
Closes #945.
Based on @diziet's comment in #945, with a little extra safety and
paranoia. We use this for cases when there are trivial changes only
in one of our crates.
Fix typos2023-07-22T07:10:34ZDimitris Apostoloudimitris.apostolou@icloud.com2023-07-22T07:10:34Zurn:sha1:947ddfff0cfac3fef0e3d7ebc14182c638a1d90bRelease.md: Add an extra semver-checks to the process.2023-06-30T16:30:44ZNick Mathewsonnickm@torproject.org2023-06-30T16:30:44Zurn:sha1:92daa577c203f97541989cee2fc8c6152fec0158
(We didn't do this previously, but it is a good idea.)
Release.md: Revise the release sections2023-06-30T16:21:48ZNick Mathewsonnickm@torproject.org2023-06-30T16:21:37Zurn:sha1:2f005a104758e69ef69230d2f521ed705eef665f
* Remove instructions to sleep
* Explain how to tag
* Remind myself about the workaround for
Fedora's delightful gpg/yubikey configuration.
* Note that we should update "pages" till the blog post is up.
Release.md: document preparation sections2023-06-30T16:18:57ZNick Mathewsonnickm@torproject.org2023-06-30T16:18:57Zurn:sha1:d0e00e4f4e362c40918a398af9e5d6df883a2d4a
I've split this into
"what I do in the days leading up to the release" and
"what I do right before the release".
There's a lot more detail now, including:
* up-to-date invocations for `cargo upgrade`
* up-to-date changelog instructions
* our current version-bumping instructions
* possible side-effects from version bumps.
Release.md: Write a tools section.2023-06-30T16:18:00ZNick Mathewsonnickm@torproject.org2023-06-30T16:18:00Zurn:sha1:451306df724debae0be2dddc1312cb95b8b90476Release.md: Write the "are we ready to release" section.2023-06-30T16:17:39ZNick Mathewsonnickm@torproject.org2023-06-30T15:39:20Zurn:sha1:a8dffab1d1c752569caf2c4c1ad5b1140bdeafc2
* Remove references to a couple of things
that our CI now does for us
(`cargo_audit` and `check_licenses`).
* Mention ~Blocker issues and MRs.
* Mention that some of our CI steps are allowed-to-fail,
but failures should be examined.
* Mention that some of our tools have exception lists
that should get reviewed.
* Mention `semver-checks` and `fixup-features`.
Release.md: Add subheadings for "how to release."2023-06-30T15:23:49ZNick Mathewsonnickm@torproject.org2023-06-30T15:23:49Zurn:sha1:de3d415a81c04557a740f83619c0dfd73b314698doc/dev/Release.md: patch release workflow2023-04-04T14:41:00ZIan Jacksonijackson@chiark.greenend.org.uk2023-04-04T14:41:00Zurn:sha1:599e2ffb7d0697e2069aeaace505ac68ae2db386
We did roughly this today. We put the CHANGELOG.md change in its own
MR, so it didn't end up in the tor-llcrypto-v0.4.4 tag. It would have
been better to do it the other way so that's what I've documented.
I couldn't test-format this with pandoc because it got tricked by some
of the `$` into trying to run TeX.