Yank log 0.1.*, 0.2.* and 0.3.0

sugar700 commented

2022-01-21 04:03:45 -06:00

(Migrated from github.com)

All log 0.1.x and 0.2.x releases don't compile on post-1.0.0 Rust due to std::rt dependency. log 0.3.0 doesn't compile outside of nightly due to #![feature(core)]. Yanking them would help cargo update -Z minimal-versions builds (rust-lang/cargo#5657). This shouldn't break ancient Rust versions, as it's unlikely that crates.io-index would work for those.

For convenience, a command to do so:

cargo yank --vers 0.1.0
cargo yank --vers 0.1.1
cargo yank --vers 0.1.2
cargo yank --vers 0.1.3
cargo yank --vers 0.1.4
cargo yank --vers 0.1.5
cargo yank --vers 0.1.6
cargo yank --vers 0.1.7
cargo yank --vers 0.1.8
cargo yank --vers 0.1.9
cargo yank --vers 0.1.10
cargo yank --vers 0.2.0
cargo yank --vers 0.2.1
cargo yank --vers 0.2.2
cargo yank --vers 0.2.3
cargo yank --vers 0.2.4
cargo yank --vers 0.2.5
cargo yank --vers 0.3.0

All log `0.1.x` and `0.2.x` releases don't compile on post-1.0.0 Rust due to `std::rt` dependency. log 0.3.0 doesn't compile outside of nightly due to `#![feature(core)]`. Yanking them would help `cargo update -Z minimal-versions` builds (rust-lang/cargo#5657). This shouldn't break ancient Rust versions, as it's unlikely that crates.io-index would work for those. For convenience, a command to do so: ```sh cargo yank --vers 0.1.0 cargo yank --vers 0.1.1 cargo yank --vers 0.1.2 cargo yank --vers 0.1.3 cargo yank --vers 0.1.4 cargo yank --vers 0.1.5 cargo yank --vers 0.1.6 cargo yank --vers 0.1.7 cargo yank --vers 0.1.8 cargo yank --vers 0.1.9 cargo yank --vers 0.1.10 cargo yank --vers 0.2.0 cargo yank --vers 0.2.1 cargo yank --vers 0.2.2 cargo yank --vers 0.2.3 cargo yank --vers 0.2.4 cargo yank --vers 0.2.5 cargo yank --vers 0.3.0 ```

KodrAus commented

2022-02-11 05:11:56 -06:00

(Migrated from github.com)

Hi @xfix 👋

Hmm, I'm trying to catch up on the context around this. It looks like the goal is to try patch around a lack of usable minimal version bounds in dependent crates.

I'm concerned about sending the wrong kind of signal here. I wouldn't expect a crate to be yanked unless there was a critical reason to do so, like a CVE disclosure. Authors could normally just decide how to manage their crates however they want, but since this project lives in the Rust organization I think we do need to be especially considerate.

I personally don't believe this is something we should do, even though those versions are mostly unusable, but would be interested to see what @rust-lang/libs thinks. You have inspired me to go add minimal version checks to our CI here in log though.

Hi @xfix :wave: Hmm, I'm trying to catch up on the context around this. It looks like the goal is to try patch around a lack of usable minimal version bounds in dependent crates. I'm concerned about sending the wrong kind of signal here. I wouldn't expect a crate to be yanked unless there was a critical reason to do so, like a CVE disclosure. Authors could normally just decide how to manage their crates however they want, but since this project lives in the Rust organization I think we do need to be especially considerate. I personally don't believe this is something we should do, even though those versions are mostly unusable, but would be interested to see what @rust-lang/libs thinks. You have inspired me to go add minimal version checks to our CI here in `log` though.

m-ou-se commented

2022-02-11 05:43:55 -06:00

(Migrated from github.com)

I agree with @KodrAus, but I don't have a strong opinion on this either way.

KodrAus commented

2022-03-22 05:05:11 -05:00

(Migrated from github.com)

It doesn't look like this is something we'll be doing so I'll go ahead and close this one. Thanks for all your effort in trying to find solutions to our past lack of attention to minimal versions @xfix! It's much appreciated.

Rows
Columns

Yank log 0.1.*, 0.2.* and 0.3.0 #480

Yank log 0.1., 0.2. and 0.3.0 #480