These crates are at version 0.x.y, so we don't need to distinguish
new-feature changes from other changes:
```
tor-basic-utils
fs-mistrust
tor-error
tor-geoip
tor-checkable
tor-linkspec
tor-netdoc
tor-netdir
tor-persist
tor-ptmgr
tor-hsservice
```
This crate has a breaking change, but only when the semver-breaking
feature `experimental-api` is enabled:
```
tor-config
```
This crate is at version 1.x.y, but has no new public APIs, and
therefore does not need a minor version bump:
```
arti
```
These crates had first-order breaking changes:
```
retry-error
tor-keymgr
tor-proto
tor-hsclient
tor-rtmock
```
Additionally, these broke because they re-exposed RetryError:
```
tor-circmgr
```
Additionally, these broke because they may re-expose something from
tor-proto:
```
arti-client
tor-chanmgr
tor-dirclient
tor-dirmgr
tor-guardmgr
```
Additionally, these broke for other fiddly reasons:
`tor-ptmgr` implements traits from tor-chanmgr, which has a breaking
change above.
`arti-hyper` exposes types from arti-client in its API.
Hiding the underlying value of `enabled` enables us to give it a
different `auto` value depending on whether the `keymgr` feature is
enabled or not (it defaults to `true` if `keymgr` is enabled, and
`false` otherwise).
The `experimental-api` was only meant to apply to the use of the
unstable `ArtiNativeKeystoreConfig` in the Arti config.
`experimental-api` was _not_ supposed to be used for enabling/disabling
the keystore (that's what the `enabled` flag is for).
I identified the cases to replace by searching for the string
`.report()`. There are a few that I didn't change:
* A couple of cases that used anyhow::Error,
* One case that reported two Errors.
* Two cases in `tor_hsclient::err` that just did
`error!("Bug: {}")`.
I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.
Nonetheless, closes#949.
Done with the commands below.
The following crates have had various changes, and should get a
patchlevel bump. Since they are pre-1.0, we do not need to
distinguish new APIs from other changes.
```
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-circmgr
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p tor-linkspec
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-netdoc
cargo set-version --bump patch -p tor-proto
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-socksproto
```
This crate has new features, but no new non-experimental Rust APIs.
So even though it is post-1.0, it gets a patchlevel bump.
```
cargo set-version --bump patch -p arti
```
`KeyStore` was renamed to `Keystore` globally in !1355. This fixes a
compile error caused an unfortunate series of non-conflicting (from
git's POV) but incompatible merges:
* !1356 added a line threferencing an error variant that capitalizes the
"s" in "KeyStore" (`ErrorDetail::KeyStore`)
* !1356 landed just before !1355 (the global renaming). Since there was
no conflict between the 2, we're now in a state where the code added
in !1356 is referencing an `ErrorDetail` variant that no longer
exists.