fern
fern copied to clipboard
daboross
Upgrade colored and prepare for 0.7.0 release
time bumped the MSRV to 1.65.0 in version 0.3.21. They (correctly) did not release this as a breaking change. But this also means that it's kind of pointless to track MSRV at all. Because we can't guarantee anything about our MSRVs when we can't do the same for our dependencies.
What we can do is to run the CI on cargo +nightly update -Z minimal-versions && cargo test to verify that our MSRV at least holds for the oldest compatible versions of all our dependencies.. Or skip the MSRV CIs completely. The maintainers need to step in here. But this issue has nothing with colored to do, it's just syslog.
We can also simply bump fern's MSRV to 1.65.0. But nothing stops our dependencies from bumping them even further with no notice.
Other options would be to run the MSRV CI with cargo update -p time --precise 0.3.20, which would only downgrade that specific crate, or committing a locally crated Cargo.lock.msrv and then doing cp Cargo.lock.msrv Cargo.lock.
Both of these would avoid the need to install nightly rust on the MSRV CI job.
Other options would be to run the MSRV CI with
cargo update -p time --precise 0.3.20...
I'll let the maintainers of fern step in here and express their wishes. But IMHO that's a very temporary and fragile solution. It's just a matter of time before some other dependency bumps their MSRV and this CI job fails for no apparent reason again. Following the same logic this crate will eventually have a large number of those workarounds to set specific versions of specific dependencies.
This PR has been left open for a while, and no new commits to main since March.
Perhaps @daboross could add some additional maintainers?
this also means that it's kind of pointless to track MSRV at all. Because we can't guarantee anything about our MSRVs when we can't do the same for our dependencies.
IMHO that's a very temporary and fragile solution. It's just a matter of time before some other dependency bumps their MSRV and this CI job fails for no apparent reason again.
You can use -Z msrv-policy with nightly toolchain to resolve crates to an MSRV if they properly maintain their rust-version in Cargo.toml.
Useful for generating a Cargo.lock.msrv for CI usage, where you may have a few crates that need version pinning if they're not compatible yet with -Z msrv-policy.
Just to clarify, a project can set an MSRV and ensure that it satisfies that MSRV via CI, but this does not require the ability to have the MSRV supported without version pinning. It's the same as what the user would need to do to build with the MSRV, bumping it to avoid any pinning is just for convenience.
rust-version in Cargo.toml should convey what the actual MSRV is to build without failure (because the project itself uses an API or a dependency that actually requires an MSRV bump to support the functionality). If you're just interested in what the MSRV is without a Cargo.lock use something like cargo-msrv in CI to track that, it's a different expectation.
Upstream dependencies can MSRV bump as non-breaking semver change without issue, especially when they leverage rust-version. This explains it well.
config-rs 0.13.x still supports a MSRV of 1.56 by using -Z msrv-policy and only three pins.
TL;DR
rust-version is where the value is at for downstreams, provided it's maintained correctly (upstreams have no impact on MSRV then when they also maintain their rust-version).
The original reason for this PR is gone (getting rid of atty as a transitive dependency). But I still think it makes sense to do this upgrade to colored 2. This gets rid of the also stale winapi crate, and in general follow the ecosystem forward. Sadly this PR also has to deal with MSRV stuff. Not really because this PR changes much around it, but because the CI for fern is currently broken if running straight off of main.
I went with the solution to check in a Cargo.lock.msrv in order to be able to maintain CI MSRV checks. However, I had to bump the lower bound on rust-version anyway, since the lockfile uses the new format introduced in Rust 1.38. Maybe it's possible to craft a lockfile of the older format :shrug: but to me that seems like madness for such an extreme backwards compatibility.
EDIT: I have not yet been able to craft a perectly working Cargo.lock.msrv. Neither of these produce a working version:
cargo updatecargo +nightly update -Z msrv-policycargo +nightly update -Z minimal-versions
But I'll continue investigating when I have time and try to handpick a combination of crates that do work.