MSRV policy is changing beginning 2023-07-01 #535
Replies: 4 comments 101 replies
-
Copying my reply from rust-lang/libs-team#72 (comment). I think that's a mistake as that means your giving people only 12 weeks of stability, forcing people to quickly move to newer rustc releases, which is not always possible.
@jhpratt not all people using compilers are developers. I think you're forgetting about, for example, (Linux) distributions which have their own stability guarantees, which for most is longer than 12 weeks. This means that any Rust application using the time crate can not be included in many Linux distributions. I really urge you to reconsider this position. |
Beta Was this translation helpful? Give feedback.
-
I can only reiterate my objections for such aggressive compiler retirements. It's unnecessarily user hostile and this will eventually backfire on the entire ecosystem if such core crates are not willing to support older compiler versions. My comment on the libc crate applies here as well: rust-lang/libs-team#72 (comment) |
Beta Was this translation helpful? Give feedback.
-
As the maintainer of a library that depends on
It was stated that "the MSRV will only be bumped when it provides a benefit to the end user", but the changelog for 0.3.20 doesn't provide any benefits to me over 0.3.19. Upgrading to 0.3.20 is, from my point of view, a chore that requires updating my own CI workflows, MSRV and even documentation(!) for no good reason other than "1.63 is an old rustc version". Quite frankly, such MSRV bumps are likely to cause downstream projects to pin the Please, can this MSRV policy be reconsidered to be a bit more slow-paced? I think it's great as-is for end applications, but it's quite unsatisfactory for libraries that want to be useful for other libraries without asking too much to anyone. Edit: moreover, I think that there is nothing that should suggest "stagnation" in keeping MSRV constant for more than 6 months if no change from newer Rust versions is needed for internal code. It's not |
Beta Was this translation helpful? Give feedback.
-
I maintain a crate that does not depend upon The MSRV of I do not want our MSRV policy to be set by yours because a crate we depend on doesn't do a good job at locking their pre-1.0 dependencies. We don't need to support older Rust versions but we want to and it is frustrating that we can't. While there's a few solutions to this, I would prefer to simply go through you before trying any of them. |
Beta Was this translation helpful? Give feedback.
-
tl;dr starting in July,
time
is adopting a stable minus two MSRV policyStarting 2023-07-01, the minimum supported Rust version policy for
time
will change. Currently, it is all Rust compilers from the previous six months are supported. Once the calendar flips to July, this will change to an "N minus two" policy. This means that the current Rust release will be supported, as well as the two before that. For example, the current stable compiler is Rust 1.66. As such the MSRV would be 1.64.Why the change? As far as I know, older compilers are not used much for development. This is due to Rust's strong commitment to backward compatibility as well as the ease of updating to a new compiler (
rustup update
is all it takes). Some users may use an older compiler provided by their distro, but this is a use case that is generally not preferred for development in Rust. While features may land on stable, I am currently prohibited by the MSRV policy from using these for a full six months. By reducing this timeframe, end users will be able to benefit from new compiler features approximately three months sooner than they would have been able to under the current policy.Does this mean that the MSRV will be bumped constantly? In a word, no. The MSRV will only be bumped when it provides a benefit to the end user. If a Rust release does not contain anything with a user-facing benefit, the MSRV will not be bumped. For example, the only feature from Rust 1.62 I plan on using is
#[derive(Default)]
onenum
s. Because this has no impact on end users, the MSRV would not be bumped. On the contrary, Rust 1.65 includes GATs. If this is determined to be useful in a public API, the MSRV could be bumped to 1.65 once Rust 1.67 hits stable. Note that the requirement is for there to be any benefit, no matter how small.Edit:
To avoid complete stagnation, the MSRV may still be bumped after six months for internal improvements. This would only apply if there have not been any features resulting in a public API improvement.
Beta Was this translation helpful? Give feedback.
All reactions