minimum Rust version?

[BurntSushi]

Is there any policy for this crate with respect to the minimum Rust version supported? In particular, it looks like CI always runs against whatever the current stable/beta/nightly releases are. So if a change gets merged that requires a newer version of Rust, you might not even realize that it happens.

(N.B. As an ecosystem, the "right" policy here is terribly unclear. I personally have been operating under a conservative policy where by bumping the minimum Rust version requires a semver bump, but I fear this won't always be tenable.)

[hsivonen]

Is there any policy for this crate with respect to the minimum Rust version supported? In particular, it looks like CI always runs against whatever the current stable/beta/nightly releases are. So if a change gets merged that requires a newer version of Rust, you might not even realize that it happens.

CONTRIBUTING.md says "Please ensure that your Contribution compiles with the latest stable-channel rustc.", so I guess that's the closest to a written policy. In practice, up to now, I've paid attention to latest stable and nightly Rust.

Now that encoding_rs is in Firefox, there's in practice also the requirement for encoding_rs to build with whatever Rust Firefox Nightly builds with. It might lag behind stable Rust if no one has gotten around to performing the update or if Rust has a known bug that forces Firefox to skip a Rust release or two.

What's your use case for supporting something older than the latest stable Rust? The reference ripgrep issue talks about Fedora but says Fedora only cares about the latest release-channel Rust.

(N.B. As an ecosystem, the "right" policy here is terribly unclear. I personally have been operating under a conservative policy where by bumping the minimum Rust version requires a semver bump, but I fear this won't always be tenable.)

I'm not sure if it's semver-wise correct, but I haven't paid attention to old Rust versions when it comes to encoding_rs semver. I've only paid attention to changes to the API of encoding_rs itself and to the rayon version, since rayon thread pool is a cross-crate shared thing even though this crate doesn't re-export any rayon API. Bumping encoding_rs semver for rayon (there seems to be an new version again) is a bit annoying, since rayon is an optional dependency and the associated feature isn't even tuned correctly at the moment and may not stay at all.

As for ecosystem concerns, I'm worrying that it could harm the progress of the Rust ecosystem if crate authors' time and effort was diverted into supporting e.g. an old Rust version shipping on an LTS Linux distro that refrains from updating Rust for years at time. (I don't mean Fedora. I mean distros like Debian stable, Ubuntu LTS, RHEL/CentOS and SUSE Linux Enterprise.) For that reason, I've had the view that the Rust ecosystem is better off positioning rustc in LTS distros as a thing that's only used for building the packages the distro ships and not as a thing that upstream crate authors are obligated to ensure builds the latest upstream crate versions.

I could be persuaded by practical reasons to support something a bit older than the latest stable Rust if there are good use cases.

[igor-raits]

@hsivonen btw, rustc/cargo for CentOS is in EPEL (Fedora repo) and we keep it in sync.. (though can't talk about RHEL whether it if/will be synced as well)

[BurntSushi]

What's your use case for supporting something older than the latest stable Rust? The reference ripgrep issue talks about Fedora but says Fedora only cares about the latest release-channel Rust.

My mind on this issue is entirely split. Note that the Fedora issue isn't the only data point. See also here and here. Ultimately though, I'd like to be able to put "ripgrep compiles with Rust 1.x or newer" in my README. In order to guarantee that, I need to test that specific version (at least) via CI. And to manage that effectively, I at least need to be aware of any related policies that my dependencies use. :-) I think you've clarified that particular question, so I think I'd consider this issue resolved.

More generally, I'm afraid of things like this happening more frequently. I worry that Rust 1.x is going to become a de facto LTS release because Linux distro Foo is shipping it, and if that can't compile my code, potential users are going to get scared away. I fully recognize the hopelessness of the situation.

I'm not sure if it's semver-wise correct

Yeah, it's a debatable point. Basically, the issue is that if I'm developing on Rust 1.x and I run cargo update, it's possible for my code to break if one my dependencies decided to increase their minimum version of Rust to 1.(x+y) in a semver compatible release. This becomes more annoying if that dependency is transitive. I think folks argue on that basis alone that it's a breaking change. Certainly, I've done such things myself (increased the minimum Rust version in a semver compatible version bump) and people have complained.

In any case, thanks for the response!

[hsivonen]

@ignatenkobrain

btw, rustc/cargo for CentOS is in EPEL (Fedora repo) and we keep it in sync

That's great. Thank you.

@BurntSushi

More generally, I'm afraid of things like this happening more frequently. I worry that Rust 1.x is going to become a de facto LTS release because Linux distro Foo is shipping it, and if that can't compile my code, potential users are going to get scared away.

I worry about Ubuntu or Debian creating a de facto LTS release, but so far, I think it would be better for the Rust community not to go along with that. I.e. I'm more worried about holding Rust back than about scaring away users. For now, the problem is being averted by Debian stretch failing to ship cargo and by Ubuntu xenial shipping something obviously too old.

At least in the case of ripgrep, there's a good chance of Debian buster (after stretch) and the next Ubuntu LTS packaging ripgrep itself, which would ease the pressure to have the latest ripgrep build with the version of Rust that Debian or Ubuntu LTS is stuck with.

Still, I added 1.15.0 to Travis and documented it in the README, but at this time I still don't want to commit to supporting 1.15.0 even though I'm OK with committing to documenting in the README if the minimum Rust version changes. I didn't put a semver bump commitment in the README, because I want to think about that one still, but I'll probably accompany a Rust version bump with a semver bump (having read the issues you linked to).

[hsivonen]

Looks like Rust 1.15.1 has been backported to Ubuntu LTS releases.

[BurntSushi]

@hsivonen I think I basically agree with you. I'll be honest and say that this has been a learning experience for me, so thank you for being patient. :-)

I'll say a couple more things quickly:

• The next release of ripgrep will require Rust 1.16.
• Even if you don't do a semver bump with a minimum Rust version bump, having a documented minimum version (even if it's just in the .travis.yml) is indeed extremely useful. Otherwise, discovering that information can take a little bit of time. :-) And I do think having this information is important regardless of the semver issue, because I want to be able to say in my README, "you need at least Rust 1.x to compile ripgrep."

[sesam]

Hey, is there any way we can band together and get this feature added somehow?

The impossibility of setting a minimum (or maximum) rustc and cargo version seems to affect many, and there's lots of discussion, but all I've found seems to have been dead ends.

<rant>I've spent >1h wading through the mess of rustc version related issues, PRs and RFCs and lost my way and posted a comment (rust-lang/cargo#2833 (comment)) in the wrong place, though can't for my life find again where it was I wanted to post it. I did convince myself that there are more people affected by these kinds of problems, and the idea that cargo would somehow, best effort and by itself, figure out which versions are compatible with which crates would be fine, but I don't see that it's been implemented, or how to influence that feature to tell grin testers to rustup to >=1.21.</rant>

[BurntSushi]

@sesam Sorry to hear about your frustration, but this is also almost certainly the wrong place to discuss Cargo/ecosystem bugs as well. I see you've already been linked to RFCs. Note though that rust-lang/rfcs#2182 is still open, but your comment seems to indicate that you think it's closed.

Additionally, there is discussion about this topic here, but sadly, there is no consensus: rust-lang/api-guidelines#123 --- So unfortunately it is not just a matter of banding together and implementing a fix. This is a hard problem to solve because the solution involves consensus building, which is both a social and a technical task.

Finally, in the aforementioned issue, I summarized my thoughts and experiences: rust-lang/api-guidelines#123 (comment)

[sesam]

Thank you. You're right, 2182 (reminds of an email related internet RFC) is open and barren compared to the other ones i mentioned. Hm. Though what I, you -kind of- and several others would need is what the title of [1707]( rust-lang/rfcs#1707) says. And the similarity of our needs is why I turned here to beg for pity :). Logically cargo would havr a repo where cargo features are debated. So confusing. I'll wrap cargo in a meta cargo then. Did you end up with a similar workaround? On Nov 27, 2017 15:46, "Andrew Gallant" <notifications@github.com> wrote: @sesam <https://github.com/sesam> Sorry to hear about your frustration, but this is also almost certainly the wrong place to discuss Cargo/ecosystem bugs as well. I see you've already been linked to RFCs. Note though that rust-lang/rfcs#2182 <rust-lang/rfcs#2182> is still open, but your comment <rust-lang/cargo#2833 (comment)> seems to indicate that you think it's closed. Additionally, there is discussion about this topic here, but sadly, there is no consensus: rust-lang/api-guidelines#123 <https://github.com/rust-lang-nursery/api-guidelines/issues/123> --- So unfortunately it is not just a matter of banding together and implementing a fix. This is a hard problem to solve because the solution involves consensus building, which is both a social and a technical task. Finally, in the aforementioned issue, I summarized my thoughts and experiences: rust-lang/api-guidelines#123 (comment) <https://github.com/rust-lang-nursery/api-guidelines/issues/123#issuecomment-342470263> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAi2Zr3V8-DI3cugPX0ZoueWaO0tgYQks5s6stHgaJpZM4N7exz> .