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

feedback wanted: do you care which version of the Rust compiler ripgrep targets? #1019

Closed
BurntSushi opened this Issue Aug 20, 2018 · 19 comments

Comments

Projects
None yet
@BurntSushi
Copy link
Owner

BurntSushi commented Aug 20, 2018

In this issue, I'm asking for feedback from any user, and I'm particularly interested in getting feedback from folks that maintain ripgrep in some package repository.

What I'd like to know is: do you care which version of the Rust compiler ripgrep targets, and if so, how does it impact you?

There are at least a couple different aspects to this question. For example:

  • That we document a minimum Rust compiler version at all.
  • That we support Rust compilers older than a few months.

My policy for this has been relatively ad hoc, but fairly conservative in the context of the Rust ecosystem. I've mostly done this out of "good sense," in that it seems better for ripgrep to compile on more versions of the Rust compiler than not. However, what I'd like to know is whether it's worth doing this. For example, if ripgrep changed to "only guaranteed to compile on the latest stable release of the Rust compiler," how would that impact you?

What I'm trying to figure out here is what kind of room I have to maneuver. For example, sometime around the end of the year, Rust 2018 will be released, and ripgrep will eventually want to move to that. What I'd like to figure out is when that kind of move would be acceptable, and in order to do that, I need to ask people how the minimum supported Rust version impacts them. So any kind of experience you can offer would be great!

cc @svenstaro @roblourens @dstcruz @joshtriplett @infinity0 @carlwgeorge @ignatenkobrain @cuviper @sylvestre

@BurntSushi BurntSushi added the question label Aug 20, 2018

@BurntSushi BurntSushi changed the title feedback wanted: do you care which version of the Rust compiler that ripgrep targets? feedback wanted: do you care which version of the Rust compiler ripgrep targets? Aug 20, 2018

@ignatenkobrain

This comment has been minimized.

Copy link
Contributor

ignatenkobrain commented Aug 20, 2018

In Fedora we will always keep latest compiler once it gets release. So "stick to the latest and coolest release"

@svenstaro

This comment has been minimized.

Copy link
Contributor

svenstaro commented Aug 20, 2018

In Arch we don't care about any compiler but the latest stable. :P

@tshepang

This comment has been minimized.

Copy link

tshepang commented Aug 20, 2018

Not to speak for Debian, but my guess is that whichever version of rustc is in Testing should be one that is supported, or one in Unstable at worst. Stable does not feature in this decision since the version of ripgrep there will not change, essentially.

@DoumanAsh

This comment has been minimized.

Copy link
Contributor

DoumanAsh commented Aug 20, 2018

As long as it targets latest stable I don't care

@sylvestre

This comment has been minimized.

Copy link
Contributor

sylvestre commented Aug 20, 2018

For debian and Ubuntu, last stable is fine.

For now, I don't think we will backport rg to debian stable.

@federicomenaquintero

This comment has been minimized.

Copy link

federicomenaquintero commented Aug 20, 2018

For openSUSE, we pick up the latest compiler version.

For SLE (Suse Linux Enterprise), we'll freeze the compiler at the version that the long-term Firefox release will require. I believe FF60 needs rustc 1.26.2, so that's what we'll use in SLE.

(For librsvg, I'm trying to tie it to the same version that Firefox requires, so that they will both work in the enterprise distro.)

@cuviper

This comment has been minimized.

Copy link

cuviper commented Aug 20, 2018

Fedora's rustc is continuously updated, as mentioned, and I update EPEL7 this way too. For RHEL proper, we're currently only shipping Rust in the Developer Tools rust-toolset, rebased quarterly.

@BurntSushi

This comment has been minimized.

Copy link
Owner Author

BurntSushi commented Aug 20, 2018

Thanks for the feedback so far! One of the things I'm interested in is figuring out the ramifications of tracking Rust stable instead of "Rust stable minus N" where N is somewhat loosely determined. I know some of you already mentioned that tracking Rust stable is fine, but for example, @federicomenaquintero, if ripgrep started tracking Rust stable, how would that impact you? Would you be able to just package last version of ripgrep that worked on the version of Rust that you're using?

@joshtriplett

This comment has been minimized.

Copy link

joshtriplett commented Aug 20, 2018

Generally speaking, if rustc isn't getting updated then neither will ripgrep. So you don't need to worry too much about the scenario where ripgrep gets updated but the update can't get packaged because rustc doesn't get updated.

The one case where that might cause a problem: if you ever need to put out an urgent bugfix for ripgrep (e.g. a hypothetical security issue parsing untrusted ignore files) then many other considerations for minimal updates and working on older rustc versions would apply.

Apart from that, using new features from the latest stable Rust seems fine in ripgrep itself. (Some of the crates ripgrep uses may have longer-term compatibility requirements.)

@BurntSushi

This comment has been minimized.

Copy link
Owner Author

BurntSushi commented Aug 20, 2018

The one case where that might cause a problem: if you ever need to put out an urgent bugfix for ripgrep (e.g. a hypothetical security issue parsing untrusted ignore files) then many other considerations for minimal updates and working on older rustc versions would apply.

Yeah that's a good one. I feel like if something like that were ever to happen, I'd just cut a branch at whatever version of ripgrep needs the fix and publish a patch release there. I don't really have the infrastructure in place to do it, and I'm not sure if I have the bandwidth to do it either, but I'd be willing to entertain the occasional backport if it's strongly motivated.

@cuviper

This comment has been minimized.

Copy link

cuviper commented Aug 20, 2018

Generally speaking, if rustc isn't getting updated then neither will ripgrep.

That's true of the packaged ripgrep. The remaining question is whether you want to support folks using their distro toolchain to cargo install ripgrep on their own.

@BurntSushi

This comment has been minimized.

Copy link
Owner Author

BurntSushi commented Aug 20, 2018

That's true of the packaged ripgrep. The remaining question is whether you want to support folks using their distro toolchain to cargo install ripgrep on their own.

Yeah, it's becoming clear to me that this will be the key thing that is lost if ripgrep were to switch to "latest stable only" policy. I'm not sure how highly to weight this use case. :-/ I do know that users appreciate being able to cargo install ripgrep, but I also feel like those with cargo installed are probably writing Rust code, and if they're writing Rust code, they're probably not on an older Rust version or are even using rustup. But I'm of course waving my hands here!

@joshtriplett

This comment has been minimized.

Copy link

joshtriplett commented Aug 20, 2018

@cuviper At one point, I worried a lot more about that, since packaging Rust software for Debian and other distros felt much further off. But I feel like, now that we have a much better story for how distributions can package software like ripgrep, and people can apt install ripgrep or equivalent in popular distributions (and other distributions have examples to follow to make that work), I'm a lot less worried about cargo install ripgrep building the latest ripgrep on old cargo/rustc. I especially don't think people should expect that to work on, say, Debian stable, or testing during a freeze.

I'd still like to see us add metadata to Cargo.toml for rustc/cargo dependencies so that we get an early, clear error message for that kind of thing. (And that would also help when generating build dependencies.) But that isn't ripgrep's problem.

@cuviper

This comment has been minimized.

Copy link

cuviper commented Aug 20, 2018

I do expect that most C and C++ software should be able to build with the system GCC, even on LTS-ish distros. (Although I admit el7's gcc-4.8.5 is now old enough to be annoying, nevermind el6, but that's why we have devtoolset.) In the long term, I expect that Rust will settle down in a similar way. For ripgrep in particular, it appears to be settling as a standard packaged distro tool too. 😄

I'd still like to see us add metadata to Cargo.toml for rustc/cargo dependencies so that we get an early, clear error message for that kind of thing.

Big 👍

@joshtriplett

This comment has been minimized.

Copy link

joshtriplett commented Aug 20, 2018

@cuviper C projects tend to adopt new C features more conservatively, not least of which due to requirements for portability to other compilers; if you need to build on the C compiler from a random proprietary UNIX, you'll probably build on old GCC too. But I've definitely found that "modern C++" software often doesn't build with LTS C++ compilers.

@Ameobea

This comment has been minimized.

Copy link

Ameobea commented Aug 20, 2018

I'm usually nightly all the time, so as long as it doesn't break every new nightly release (looking at you clippy) I'm happy.

@dcarosone

This comment has been minimized.

Copy link

dcarosone commented Aug 21, 2018

Nightly on anything where rustup works, and/or pkgsrc on smartos + netbsd

@BurntSushi

This comment has been minimized.

Copy link
Owner Author

BurntSushi commented Aug 21, 2018

All righty, based on the feedback I've got so far, I'm going to try switching to a latest stable policy for the next release. In detail, it will probably look like this:

  • Every patch release will compile on the same version of the Rust compiler as the previous patch release.
  • New minor version releases of ripgrep may require a Rust compiler as recent as the latest stable release.

I think this should satisfy most everyone who commented, and should also let us backport patches if that becomes necessary.

If this doesn't work out for some reason or another, we can revert to a more conservative policy, but the benefits of sticking the latest stable release are too big to not try this at all.

@roblourens - I don't think I've heard from you on this, but I think you build your own ripgrep and probably easily control the version of the Rust compiler you use.

I also don't think I heard from any folks using Homebrew, but IIRC, they track the latest stable version of Rust as well.

@roblourens

This comment has been minimized.

Copy link
Contributor

roblourens commented Aug 21, 2018

That's right, I usually just update to the latest stable each time I build it.

BurntSushi added a commit that referenced this issue Aug 22, 2018

ripgrep: move minimum version to Rust stable
This also updates some code to make use of our more liberal versioning
requirement, including the use of crossbeam-channel instead of the MsQueue
from the older an unmaintained crossbeam 0.3. This does regrettably add
a sizable number of dependencies, however, compile times seem mostly
unaffected.

Closes #1019

BurntSushi added a commit that referenced this issue Aug 22, 2018

ripgrep: move minimum version to Rust stable
This also updates some code to make use of our more liberal versioning
requirement, including the use of crossbeam-channel instead of the MsQueue
from the older an unmaintained crossbeam 0.3. This does regrettably add
a sizable number of dependencies, however, compile times seem mostly
unaffected.

Closes #1019

BurntSushi added a commit that referenced this issue Aug 22, 2018

ripgrep: move minimum version to Rust stable
This also updates some code to make use of our more liberal versioning
requirement, including the use of crossbeam-channel instead of the MsQueue
from the older an unmaintained crossbeam 0.3. This does regrettably add
a sizable number of dependencies, however, compile times seem mostly
unaffected.

Closes #1019

BurntSushi added a commit that referenced this issue Aug 22, 2018

ripgrep: move minimum version to Rust stable
This also updates some code to make use of our more liberal versioning
requirement, including the use of crossbeam-channel instead of the MsQueue
from the older an unmaintained crossbeam 0.3. This does regrettably add
a sizable number of dependencies, however, compile times seem mostly
unaffected.

Closes #1019

BurntSushi added a commit to BurntSushi/xsv that referenced this issue Aug 25, 2018

deps: update to quickcheck 0.7
This also updates the rand crate.

We bump the minimum Rust version to the latest stable, Rust 1.28.0.

See: BurntSushi/ripgrep#1019

Jehops pushed a commit to Jehops/freebsd-ports that referenced this issue Sep 28, 2018

Bump minimum Rust version in Mk/Uses/cargo.mk
Given that at least ripgrep will soon require Rust >= 1.28.0 [1]
and given the recently discovered buffer overflow vulnerability in
the standard library of Rust < 1.29.1 [2] bump it to 1.29.1 to avoid
surprises.

[1] BurntSushi/ripgrep#1019
[2] https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@480877 35697150-7ecd-e111-bb59-0022644237b5

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Sep 28, 2018

tobik
Bump minimum Rust version in Mk/Uses/cargo.mk
Given that at least ripgrep will soon require Rust >= 1.28.0 [1]
and given the recently discovered buffer overflow vulnerability in
the standard library of Rust < 1.29.1 [2] bump it to 1.29.1 to avoid
surprises.

[1] BurntSushi/ripgrep#1019
[2] https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@480877 35697150-7ecd-e111-bb59-0022644237b5

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Sep 28, 2018

Bump minimum Rust version in Mk/Uses/cargo.mk
Given that at least ripgrep will soon require Rust >= 1.28.0 [1]
and given the recently discovered buffer overflow vulnerability in
the standard library of Rust < 1.29.1 [2] bump it to 1.29.1 to avoid
surprises.

[1] BurntSushi/ripgrep#1019
[2] https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0

mat813 pushed a commit to mat813/freebsd-ports that referenced this issue Sep 28, 2018

Bump minimum Rust version in Mk/Uses/cargo.mk
Given that at least ripgrep will soon require Rust >= 1.28.0 [1]
and given the recently discovered buffer overflow vulnerability in
the standard library of Rust < 1.29.1 [2] bump it to 1.29.1 to avoid
surprises.

[1] BurntSushi/ripgrep#1019
[2] https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0


git-svn-id: https://svn.freebsd.org/ports/head@480877 35697150-7ecd-e111-bb59-0022644237b5

t6 added a commit to t6/freebsd-ports-sndio that referenced this issue Sep 29, 2018

Bump minimum Rust version in Mk/Uses/cargo.mk
Given that at least ripgrep will soon require Rust >= 1.28.0 [1]
and given the recently discovered buffer overflow vulnerability in
the standard library of Rust < 1.29.1 [2] bump it to 1.29.1 to avoid
surprises.

[1] BurntSushi/ripgrep#1019
[2] https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0

swills pushed a commit to swills/freebsd-ports that referenced this issue Sep 29, 2018

Bump minimum Rust version in Mk/Uses/cargo.mk
Given that at least ripgrep will soon require Rust >= 1.28.0 [1]
and given the recently discovered buffer overflow vulnerability in
the standard library of Rust < 1.29.1 [2] bump it to 1.29.1 to avoid
surprises.

[1] BurntSushi/ripgrep#1019
[2] https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@480877 35697150-7ecd-e111-bb59-0022644237b5

t6 added a commit to t6/freebsd-ports-sndio that referenced this issue Sep 29, 2018

Bump minimum Rust version in Mk/Uses/cargo.mk
Given that at least ripgrep will soon require Rust >= 1.28.0 [1]
and given the recently discovered buffer overflow vulnerability in
the standard library of Rust < 1.29.1 [2] bump it to 1.29.1 to avoid
surprises.

[1] BurntSushi/ripgrep#1019
[2] https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment