Yank log 0.1.*, 0.2.* and 0.3.0

[sugar700]

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

[KodrAus]

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.

[m-ou-se]

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

[KodrAus]

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.