These crates have had trivial changes only: typically,
changes to documentation or to clippy warnings. There's no
good reason to update which version of them other crates depend on,
so we only bump _their_ patchlevels.
```
tor-async-utils
caret
safelog
tor-events
tor-units
tor-rtcompat
tor-rpcbase
tor-llcrypto
tor-protover
tor-bytes
tor-hscrypto
tor-socksproto
tor-cert
tor-cell
tor-consdiff
tor-congestion
arti-rpcserver
arti-testing
arti-bench
arti-config
arti-hyper
```
These crates have had nonfunctional changes only, mostly due to !1271,
or ac90cb7500, or documentation changes: crates that depend on
them do not require a version bump.
```
arti-bench
arti-config
arti-hyper
arti-testing
caret
fs-mistrust
retry-error
tor-async-utils
tor-basic-utils
tor-chanmgr
tor-checkable
tor-congestion
tor-consdiff
tor-events
tor-guardmgr
tor-persist
tor-protover
tor-ptmgr
tor-rtcompat
tor-rtmock
tor-units
```
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`.
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes#748.
The feature we want is `#[doc = include_str!("README.md")]`, which is
stable since 1.54 and our MSRV is now 1.56.
This commit is precisely the result of the following Perl rune:
perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
Since our last round of releases, these crates have had either
trivial changes, or changes that did not affect their APIs.
Therefore we are bumping their versions, but not changing which
versions of them other crates depend on.
"Trivial" here includes stuff like cargo reformatting, comment
edits, error message string changes, and clippy warning changes.
Crates that depend on these do not need to increment.
I was looking to see if we could delete this altogether but I
discovered that on lib.rs the description does not say it's a removed
crate, in the summaries.
Fix this.
I followed the following procedure to make these changes:
* I used maint/changed_crates to find out which crates had changed
since 0.3.0.
* I used grep and maint/list_crates to sort those crates in
topological (dependency) order.
* I looked through semver_status to find which crates were listed as
having semver-relevant changes (new APIs and breaking changes).
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no changes. For those crates, I incremented their patch-level
version _without_ changing the version that other crates depend on.
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no obvious breaking changes.
* I treated all crates that depend on `arti` and/or `arti-client` as
having breaking changes.
* I identified crates that depend on crates that have changed, even
if they have not changed themselves, and identified them as having
a non-breaking change.
* For all of the crates, I used `cargo set-version -p $CRATE --bump
$STATUS` (where `STATUS` is `patch` or `minor`) to update the
versions, and the depended-upon versions.
This crate no longer has any reason to exist. All its remaining
functionality is generic enough to go into tor-config.
In this commit, we move the contents of lib.rs into a new file in
tor-config. It contains:
* Code motion
* The minimal "mod" and "use" changes
* The minimal doc comment
* A new a compat alias for ConfigurationSources.
The compat alias is there because various crates currently speak of
arti_config::ConfigurationSources and it is most convenient to fix
them up after the type is available in tor_config.
This is redundant, because the defaults have to be supplied by the
config builders (usually via builder default attributes).
That this is actually done and correct is tested by the
`default_config()` test case in arti/src/cfg.rs.
These generic arguments weren't consistent. It doesn't make sense ot
insist on getting a borrowed type and then cloning it. So tidy things
up in the direction of taking owned values, which is what
ConfigurationSources actually needs.
(My personal preference would be &dyn to avoid monomorphisation code
bloat but that was controversial last time I proposed it somewhere.)
For reference, the git source for this crate (and the others in its
workspace) currently lives in my personal github account (ijackson).
If this fork turns out to be long-lived and gains features and/or
users, it would be good to move it to a gitlab somewhere.
I have granted Nick crate ownership on the crates.io system.
The `[patch]` approach causes the tree not to build when used as a
dependency, unless the `[patch]` is replicated into the depending
project.
Instead, replace our `derive_builer =` dependencies with a reference
to a specific git commit:
perl -i~ -pe 'next unless m/^derive_builder/; s#"(0\.11\.2)"#{ version = "$1", git = "https://github.com/ijackson/rust-derive-builder", rev = "ba0c1a5311bd9f93ddf5f5b8ec2a5f6f03b22fbe" }#' crates/*/Cargo.toml
Note that the commitid has changed. This is because derive_builder is
in fact a workspace of 4 crates. 3 of them are of interest to arti
itself (the 4th exists only for testing). So the same "add git
revision" treatment had to be done to the `derive_builder` and
`derive_builder_macro` crates. Each dependency edge involves a new
commit in the derive_builder workspace, since we can't create a git
commit containing its own commitid. (We want to use commits, rather
than a branch, so that what we are depending on is actually properly
defined, and not subject to the whims of my personal github
namespace.)
There are no actual code changes in derive_builder.
Nick Mathewson
Ian Jackson
Emil Engler
trinity-1686a
Ian Jackson
eta
Samanta Navarro