minimum Rust version? #18
Comments
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.
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. |
|
@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) |
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.
Yeah, it's a debatable point. Basically, the issue is that if I'm developing on Rust 1.x and I run In any case, thanks for the response! |
That's great. Thank you.
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). |
|
Looks like Rust 1.15.1 has been backported to Ubuntu LTS releases. |
|
@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:
|
|
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.
|
|
@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) |
|
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" <[email protected]> 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>
.
|
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.)
The text was updated successfully, but these errors were encountered: