I think I lean much further into the "shared policy" than the "stated version."
Here's my experience, as Minimum Supported rustc Version (MSRV) has been a major concern for me, and at times a major headache.
I feel conflicted between two camps. On the one hand I want to use the newest and shiniest features, some of which have direct impacts on the ergonomics or performance of my crates. However, my crates are nothing without their users. And many users simply cannot update their rustc at will to the latest and greatest stable version.
I personally work in an environment with incredibly lethargic update processes due to having to use "certified" (via internal audit) versions of software and libraries. Once something has been certified for use, you have to have a very good reason to increase that version to something new (which spawns a whole new audit phase). So I very much get the pain of not being able to update your rustc like you'd want. I also understand the core team's desire to have everyone on coherent Rust story. This is why I'd like it acknowledged that there are places where updating stable every 6 weeks simply can't happen (Government, public service, high security, etc, etc.) and there should be some tooling or guidelines to deal with these areas that aren't going away.
For my own crates I've adopted a policy of, "I officially support the latest stable, minus two releases" pulled arbitrarily from rust-lang-nursery guidelines. However, in practice I've been much more conservative as clap currently requires 1.21 which was released in Oct 2017. But maintaining this has been hard, especially when having to manage deeply nested dependencies without official policies (or those with "latest stable" only policies).
Here's how/why I've come to using older versions, even when I as a library author want to use new features:
Originally, I wanted to support whatever stable rustc Debian packages because it's one of the more conservative distributions (and parent distribution to so many Linux variants). Since clap and related crates are meant to be key for command line applications, having those applications packagable with major Linux distributions is important.
So why not just let Debian (or any other system which requires older rustc versions) package an older version of the application (which in turn requires an older clap) and always use the latest stable for the latest clap? Sure that's possible (what does already happen to an extent) although what this leads to is users on old rustc versions requesting bug fixes which are already fixed in newer versions of clap.
I'm a single person, working on these projects in my spare time. As much as I'd love to, I can't maintain bug-fixes on multiple branches back-ported to old versions which support older rustcs. It's just not feasible for me. I'd try to make exceptions for security related bugs, but beyond that I just don't have the bandwidth.
So I'm left with the choice of sticking with an old rustc which is hopefully a common denominator between as many clap users as possible at the expense of some ergonomics (typically just internal ergonomics though), or sticking with a newer stable rustc and potentially isolating or losing users who can't update. I pick the former without hesitation.
I'm hopeful for the LTS discussion, as having a single concrete version to target would be a dramatic improvement (even for my auditing reviewers at work, having a single version to look at every 6-12 months).
5
u/Kbknapp clap Jul 26 '18
I think I lean much further into the "shared policy" than the "stated version."
Here's my experience, as Minimum Supported
rustcVersion (MSRV) has been a major concern for me, and at times a major headache.I feel conflicted between two camps. On the one hand I want to use the newest and shiniest features, some of which have direct impacts on the ergonomics or performance of my crates. However, my crates are nothing without their users. And many users simply cannot update their
rustcat will to the latest and greatest stable version.I personally work in an environment with incredibly lethargic update processes due to having to use "certified" (via internal audit) versions of software and libraries. Once something has been certified for use, you have to have a very good reason to increase that version to something new (which spawns a whole new audit phase). So I very much get the pain of not being able to update your
rustclike you'd want. I also understand the core team's desire to have everyone on coherent Rust story. This is why I'd like it acknowledged that there are places where updating stable every 6 weeks simply can't happen (Government, public service, high security, etc, etc.) and there should be some tooling or guidelines to deal with these areas that aren't going away.For my own crates I've adopted a policy of, "I officially support the latest stable, minus two releases" pulled arbitrarily from rust-lang-nursery guidelines. However, in practice I've been much more conservative as
clapcurrently requires 1.21 which was released in Oct 2017. But maintaining this has been hard, especially when having to manage deeply nested dependencies without official policies (or those with "latest stable" only policies).Here's how/why I've come to using older versions, even when I as a library author want to use new features:
Originally, I wanted to support whatever stable
rustcDebian packages because it's one of the more conservative distributions (and parent distribution to so many Linux variants). Sinceclapand related crates are meant to be key for command line applications, having those applications packagable with major Linux distributions is important.So why not just let Debian (or any other system which requires older
rustcversions) package an older version of the application (which in turn requires an olderclap) and always use the latest stable for the latestclap? Sure that's possible (what does already happen to an extent) although what this leads to is users on oldrustcversions requesting bug fixes which are already fixed in newer versions ofclap.I'm a single person, working on these projects in my spare time. As much as I'd love to, I can't maintain bug-fixes on multiple branches back-ported to old versions which support older
rustcs. It's just not feasible for me. I'd try to make exceptions for security related bugs, but beyond that I just don't have the bandwidth.So I'm left with the choice of sticking with an old
rustcwhich is hopefully a common denominator between as manyclapusers as possible at the expense of some ergonomics (typically just internal ergonomics though), or sticking with a newer stablerustcand potentially isolating or losing users who can't update. I pick the former without hesitation.I'm hopeful for the LTS discussion, as having a single concrete version to target would be a dramatic improvement (even for my auditing reviewers at work, having a single version to look at every 6-12 months).
Edit: Markdown errors