Closed Dekkonot closed 1 year ago
Was going to pile on here, but noticed that there's already a discussion about this policy here. @Dekkonot, it might be better to add your voice there.
As indicated, there is an existing thread to discuss MSRV policy. Please use that thread to explain, with sufficient details, why a low MSRV is fundamentally necessary. Being able to use new language features (after some delay) is essential. It's for that reason that an unchanging MSRV will never be the case for a crate maintained by me; it's only a matter of when bumping is acceptable.
With regard to time
not being 1.0, that's breakage just for the sake of breakage. There is nothing gained by time
being 1.0 versus the current 0.3, nor do I believe that time
should be 1.0 at this point in time. There are multiple language features that I want to see implemented and stabilized before I release a 1.0 version. Finally, being 1.0 does not in any way imply a "stable release schedule". I am not aware of a single crate that does this.
As of the last release (v0.3.21), our CI started failing despite us not changing any code. We do not depend on
time
directly, so we cannot downgrade it. We simply have to up our MSRV to continue building.time
is used extensively throughout the entire Rust ecosystem. It's downloaded 100k+ times a day according to crates.io. It's used all over the place in production by thousands of people. It's far past time to stop being a pre-1.0 crate and move towards having a stable release schedule that doesn't make breaking changes in patch releases.This is an unusually bold request and I recognize that. But as someone whose CI broke today over something I cannot control, I am feeling particularly bold. Please consider this.