Please lower the MSRV #3267
Comments
|
I can understand the limitation of clap3's MSRV making it more difficult to update from clap2. This request is to lower the MSRV to a specific number but what I'm wondering is how this affects our MSRV policy. Clap's MSRV policy has always been "2 back" (though without any non-patch releases in a long time, it has artificially extended the MSRV). How long are you requesting we stay on 1.52 or earlier? What would we be able to upgrade to after that? Effectively, is this a one-time request or a request to change our MSRV policy to something else and, if so, what? |
|
Forgot to add, |
|
I guess it's more about the policy. IMO clap is an important crate which, apart from CLIs which might arguably not have as strict MSRV requirements, is also used often in examples for library projects. (For example, Quinn and Trust-DNS are libraries currently using structopt in their repositories -- rustls has been using docopt, which is unmaintained.) As such, I think a more conservative MSRV policy would be appropriate for this project. MSRV bumps should come with sufficient justification unless the bump is about a very old release (so the bump in os_str_bytes for the sole purpose of enabling some lint looks bad to me). For Quinn (currently at 1.51.0), we try to match the Tokio project which has a 6 month policy but actually ends up more conservative (currently at 1.46.0). Some recent discussion: https://twitter.com/mitsuhiko/status/1479832038257704964 |
|
I feel like this is another example of the curse of clap3 taking too long 😄 . The other being a subset of people who basically want the same time span before future breaking changes. I assume those crates have to hold back dependencies. Is there a reason they are not wanting to hold clap back but upgrade? Would a temporary lowering of MSRV for upgrade but then a resuming of regular policy meet those needs? We have competing care abouts from maintainers (access to functionality and fixes, low process overhead) and different user bases (accelerated development vs low churn in API breaks of MSRV). I would say our primary target user is the CLI developer who is wanting further improvements at the cost of churn. A breakdown of challenges: So as alluded to, we are constrained by our dependencies. There are tiers to this:
If we supported testing and all features on all crates, that greatly increases the number of dependencies (see below). The easiest to verify is if we support all features on all targets on all crates. Different slices and dices of this get messy. We'd end up having to hold back more dependencies for MSRV. We also have to balance holding back dependency upgrades with our users who are trying to minimize the number of duplicate dependencies (e.g. TeXitoi/structopt#518). This also limits what features and bug fixes we get access to in those dependencies or from the dependencies we can't use because of the policy. Dependencies aren't the only consideration. The proposal would basically require us to prepare to litigate whether an MSRV upgrade is justified (and possibly go through those conversations like is partially happening here) for various user bases which aren't our primary target (CLIs). Any MSRV also introduces challenges and this would exacerbate it, like dealing with new lints that need to be silenced in macros. Dependencies of just |
|
I think the reality is that's quite feasible even if it might seem daunting at first. Let's review direct library dependencies for clap and clap_derive:
In other words, the minimum bounds seem to be:
I don't think, with the current state of Rust, the MSRV really needs to constrain feature development; at least that's not my experience. There's almost always a straightforward fix, and if it will be pointed out by CI the contributor will likely quickly take care of it.
That seems fine, a single MSRV for the entire repository is what pretty much all projects do.
I'm generally not asking you to hold back dependency upgrades (I always do them ASAP). When a dependency comes with a significant MSRV bump to something that's a little fresh for my projects' MSRV policy, I've sometimes gone upstream to request a reassessment of that change, and maintainers have usually been responsive to that kind of argument (especially for the kind of widely used dependencies you seem to have here).
If you stick to 6-9 months (4-6 releases) I think it'll almost never be a big deal -- it certainly hasn't been for most of the projects I maintain. |
|
How about we give this a trial. If a contributor is willing to step in and create PRs to make all of the dependencies work on the proposed MSRV and they get accepted by the maintainers, we can provisionally (and unofficially) lower the MSRV. After a period of time (6 months?), we can re-evaluate and possibly adjust the MSRV policy. If there are problems with the provisional MSRV, we reserve the right to revert it, even in a patch release (hence the unofficial designation). Depending on what happened, a contributor can step in to help lower it again and we can consider trying this again. |
epage
added
A-meta
|
What do you mean by "provisionally (and unofficially)"? Do you mean you don't change the documentation about the MSRV? Can we still lower the MSRV in CI? Without changing it in CI setting an unofficial lower MSRV is pointless, as it will be a pain to figure out what changes are violating the unofficial MSRV. I propose we make changes in this repository to support 1.52 as the unofficial MSRV and enforce this in CI. If there is a PR that runs into MSRV issues that violate an unofficial 6-month policy (which would actually be 1.53, but we get one release for free), I'm happy to jump in to see if there's a way out. |
|
Provisional: this is on a trial bases, like 6 months Unofficial: we reserve the right to change MSRV on patch releases. We probably won't advertise this MSRV. I agree about checking it in CI. |
epage
added
E-medium
|
Okay, I'm going to give up on reducing MSRV below 1.54 since it's now been 6 months anyway. Let's see if we can stick to 1.54 as the unofficial CI-checked MSRV for now, though. |
This is needed for `Bound::cloned` and fits within official MSRV policy (2 versions back) and unofficial (6 months, see clap-rs#3267)
This is needed for `Bound::cloned` and fits within official MSRV policy (2 versions back) and unofficial (6 months, see clap-rs#3267)
|
clap's current MSRV is less than 2 months old.. Is it unreasonable to ask for a longer MSRV than 2 months? Debian is at 1.63, Guix is at 1.68. I don't think supporting a Rust version for at least a year is unreasonable to ask.. |
|
Our stated policy has been "We will support the last two minor Rust releases". We have occasionally stretched it to be older as an experiment to see how well that works. However, the value of being able to access the Clap's policy is fairly common in the ecosystem. Personally, tracking MSRV policy to something like Debian is a non-starter. 1.63 sounds new-ish now (though it misses workspace inheritance which is a big help for maintainers) but what will that look like in a year or two? Until recently, Debian was using 1.41 which was pretty ancient in Rust terms by the time they updated. Note that the cargo has changed its guidance on committing lockfiles. The new guidance is do what works for your project with committing as the default choice (expect a rust-lang blog post soon talking about this). I highly encourage anyone maintaining an MSRV to commit their lockfile (it was one of the motivating reasons for me to push that policy change). I also hope that soon I'll be able to get back to making cargo's resolver MSRV aware. |
|
2 months is incredibly short, though.. I can see that a large project might have a larger incentive than some smaller projects to upgrade (I still maintain 1.29 in some projects and generally we support 1.48 now), but even a really tempting new shiny thing can wait more than 2 months, right? But yeah you're right, lockfiles help in almost all such cases. Having msrv taken into account in the resolver would make it so much easier. If you can get that to work in cargo, you'd be Rust Hero Number One, granted. |
|
MSRV-aware resolver is now in nightly under |
|
... and I had to look this far to find the actual MSRV policy (and related discussion). Please make it clearer (e.g. put it in the README). Going by the broken link above, I'm guessing it was removed at some point? |
|
We've tried to centralize our documentation on docs.rs. For the MSRV policy, see https://docs.rs/clap/latest/clap/#aspirations |
Maintainer's notes
Disposition comment
To clarify, yes, we can check this unofficial, provisional MSRV in CI
Please complete the following tasks
Clap Version
3.0.5
Describe your use case
Currently I'd like to use clap (with derive) in the example code for the rustls-mio crate. However, the rustls repo currently has CI set to a 1.52.1 MSRV (and realistically I'd prefer to stick with 1.51 or even 1.50).
Describe the solution you'd like
I'd like the MSRV to be ideally no younger than 1.50. 1.51 would also be okay, maybe 1.52.
Alternatives, if applicable
No response
Additional Context
So far I found the
#![doc = include_str!()]usage inclap_deriveand the use ofos_str_byteswhich currently requires 1.52 (but apparently only because it wants to support some lint, which seems like a pretty bad reason). I'm not sure how important os_str_bytes is to this crate's mechanics; maybe relying on the platform-specificOsStrExtimplementations could go a long way?The text was updated successfully, but these errors were encountered: