-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
what is the policy around minimum supported version of Rust? #740
Comments
This is a good question, thanks for bringing it up! It's also one I was thinking about while pushing that particular PR. When pushing that PR I had that odd feeling in the pit of my stomach too, which should have been a sign! As part of that PR my thought process was obviously at least bump the minor because I regularly use While no official policy is in place, I think it may be time to adopt one. I went through and read those RFCs you linked to, and had seen them briefly in the past. I can see how this can be contentious, and personally I'm seeing myself leaning more towards the major version bump side of things, although it does scare me to think of making multiple major version bumps relatively rapidly. In my mind, the more people bump the major version and only provide extremely small breaking changes you're conditioning the users of your library to expect small breaking changes, if any. Then one day you break everything for what should truly be a major version bump, and it'll throw people off. Moving ForwardHere's my plan moving forward. I'm going to roll back #737 and use the Stable-2 approach for officially supported. And for the time being at least until Rust decides an official best practices policy. I will make bumping the minimum version of This to me seems the best approach for this project at this time. My reasoning is the way this project is structured, one typically doesn't need to bump the minor version unless you're using one of the newer features released in said minor. It's true that there are bug fixes in future minors that aren't back-ported (because I don't have enough man power to do so), but unless you're affected by one of these bugs which in most cases is a small percentage of users anyways, you really don't have a reason to bump the minor. All this meaning, bumping the minor could, and perhaps should, be a conscious decision. Thoughts? I'm open to any and all suggestions! |
@kbknapp That seems like a good compromise to me! Thanks for taking the time. :-) (Loving clap so far btw!) |
Thanks! 😄 TODO:
|
@BurntSushi 👍 on putting a specific compiler into |
Yep, I've got a local branch where I'm working on some of these fixes and that was one of the first things I did 😄 I should have the PR in today or tomorrow. |
When clap gets an addition that requires a newer version of Rust, what is the policy regarding semver updates?
For example, PR #737 increased the minimum Rust version required to build clap from 1.11.0 (which can compile clap 2.18.0) to 1.13.0 (which is required because of the
questionmark
feature being recently stabilized).This is a problem in practice for folks that need or want to support older versions of the Rust compiler specifically because
cargo update
will cause builds to break. e.g.,cargo update
will do a semver upgrade from clap2.18.0
to clap2.19.0
(once it's released), but this will break every single build on Rust 1.11 and Rust 1.12. There are solutions to the problem, such as adding a version constraint like<= 2.18.0
to one's Cargo.toml. Typically, this can be a particularly nasty problem when the issue lies in a transitive dependency. In clap's case at least, it's likely to not be a transitive dependency, which probably makes it a little easier to deal with.Note that this has been a contentious issue discussed at length. Some people think it qualifies as a breaking change, and therefore requires a semver version bump (in clap's case, a major version bump). Others think the constraints it places on projects are too onerous and will be hard to live up to in practice. See rust-lang/rfcs#1619 for more discussion. See also: https://users.rust-lang.org/t/cargo-lock-libraries-and-ci/7698 --- Either way, I think it's important to establish a policy. One way to be proactive about it is (regardless of which side you come down on) is to put a specific Rust version in your CI testing. That way, you'll at least know when it happens, because it can otherwise be very tricky to keep track of!
The text was updated successfully, but these errors were encountered: