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
```
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
```
This does the following:
- Gives every crate a `full`.
- Cause every `full` to depend on `full` from the lower-level
crates.
- Makes every feature listed _directly_ in `experimental` depend
on `__is_experimental`.
Relays and onion service services/clients will both need this.
I'm marking this experimental for now; we should stabilize it before
we release onion services.
If we didn't do this, we would need to transfrom
`EncodedLinkSpec`s into a `LinkSpec::Unrecognized`, which is not
semantically right. What's more, every user of this API wants to
consume encoded link specifiers, so encoding them early saves a
little effort.
This commit adds functions to convert between LinkSpec and
EncodedLinkSpec, and refactors their read/write implementations a
bit to avoid code duplication.
This change is necessary so that we can build Extend2 messages
that have their LinkSpecs appear in a verbatim order as provided
in an INTRODUCE2 message or in a HS descriptor.
These crates had no changes until just a moment ago. But since
we updated the versions on some of their dependents, they have now
changed themselves. Thus they get patchlevel bumps.
```
tor-rtmock
tor-protover
tor-socksproto
tor-consdiff
tor-chanmgr
tor-dirclient
tor-hsservice
```
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
Unlike linkspec, this doesn't validate the actual contents of the
specifiers. We'll use this so we can handle the linkspec list for an
introduction point in an HsDesc, and just pass it on when
constructing our circuits.
I haven't added any accessor or constructor functions, because I
don't expect to need them.