cargo-semver-checks, semver.md
Prompt
@juga had been using tor_cirmgr::path
. We made that no longer pub
following !2046 (comment 3010217), which was released in tor-circmgr
0.17 (Arti 1.2.1). We helped them and it looks like they can use the circuit construction machinery instead, but:
The removal of this module (rather, than, say, deprecating it) wasn't really consistent with our doc/Semver.md
policy. We (@gabi-250 and I) now regard it as a mistake. We should probably have retained it as #[deprecated]
for a period of time.
semver.md
In #1005 (comment 2991812) we agreed that we would no longer track semver changes in semver.md
. However, it turns out that doing so is valuable when trying to write the changelog. The changelog definitely ought to contain information about breaking changes.
IOW I now think my proposal there to drop semver.md was a mistake.
cargo-semver-checks
cargo-semver-checks
in the release of 1.2.1 (tor-circmgr 0.17) was another opportunity to catch this mistake. But Release.md
isn't quite clear on what to do about the output of cargo-semver-checks
.
Action items
ISTM that the release technician for 0.17 ought to have been guided by our process docs to query this module's removal and recommend deprecation instead. This consideration should probably have been done while preparing the changelog, since that's a user-focused activity. It should have been prompted by semver.md
backed up by cargo-semver-checks
to try to make sure the semver.md
information was up to date.
- Reinstate our semver.md practice. (I'm not sure if this was ever documented in tree, but if not it should be.)
- Update
Release.md
to guide the changelog author to consider breaking changes from a user's pov, with reference to our policy. - Update
Release.md
to be a bit clearer about what to do withcargo-semver-checks
output
CC @nickm