what is the policy around minimum supported version of Rust?

[BurntSushi]

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 clap 2.18.0 to clap 2.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!

[kbknapp]

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 "~2.18.0" styles in my Cargo.toml in order to not automatically bump minors for cases like this. I also forgo that many people use "2" (or similar) in theirs.

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 Forward

Here'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 rustc a minor version bump but will also very clearly dictate the "stable-2, and use "~major.minor.patch" in your Cargo.toml to avoid being caught off guard" in the readme and docs, as well as make it clear in the changelog when the minimum version of rustc has been bumped.

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!

[BurntSushi]

@kbknapp That seems like a good compromise to me! Thanks for taking the time. :-)

(Loving clap so far btw!)

[kbknapp]

Thanks! 😄

TODO:

• Revert Questionmark #737
• Update README.md with new policy
• Add 1.11.0 to .travis.yml

[BurntSushi]

@kbknapp One thing to consider adding to your TODO list is to put a specific Rust version in your .travis.yml. Example.

[matthiasbeyer]

@BurntSushi 👍 on putting a specific compiler into .travis.yml! I'd suggest at least one compiler that does not support the ? syntax, at least for the next few weeks.

[kbknapp]

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.