-
Notifications
You must be signed in to change notification settings - Fork 654
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
Decide on a rust version support policy #238
Comments
I commented on #237 saying that I think 1.3.0 is good for the oldest official Rust support for now. |
On the topic, what are the pros/cons of supporting older versions? Eg could we support as far back as 1.0.0? (I only started writing Rust a month or two ago, so I don't know what's changed.) |
Mostly a question of who is using nix and if they "freeze" their version of Rust. I know that some production Rust users who depend on "unstable" Rust features have frozen version of Rust used internally and only occasionally update it. That's really the only reason. |
Ok. I've made it 1.1.0+ for now. I'll look into the errors with 1.0.0 to see how reasonable it is to attempt to support all released versions. |
I would prefer not to allow failures on nightly. I see three cases why it might fail:
|
I've seen broken nightly make my PRs go red at least a couple of times. On the flip side, the stability guarantee means we shouldn't see any language changes that cause breakage. And if they do happen, there will be an entire beta cycle to fix them. We an also keep tabs on nightly ourselves, since it'll be run on every PR. |
Or summarising:
We should see it in other releases and fix it.
Shouldn't happen.
Annoying and disruptive. (Subjective, of course.) |
@arcnmx any thoughts on this? You have some changes in mind that seem to assume bleeding edge rust... |
It'd be nice if they raised warnings so we can audit why it failed, but in general it seems fine to me. Failing on nightly, unless we were to use some unstable features, should be considered a rustc bug. Recently this was the case with the
My general behaviour is to track stable+ and that's it (nix is the first project I've seen that attempts to support back so many versions). There's nothing inherently wrong with it though, and my changes have workarounds that aren't particularly annoying to deal with, so I don't really mind either way. On the other hand, I'm not sure there's much to be gained from guaranteeing support so far back. The language is backwards-compat, so there's not much reason to actually be on an old version of rustc. The ecosystem/community is pretty aggressive about updating, and anyone "freezing" is indeed usually tracking closer to nightly/beta than anything else. |
There's some additional discussion over on users.rust-lang.org: https://users.rust-lang.org/t/rust-version-support-in-library-crates-best-practices/4405 |
There hasn't been much recent conversation here. My personal preference is to support as far back as possible. This is the same policy libc has. I'm working on a couple of things that should make this easier to achieve. Hopefully they'll be releasable in a week or so. For the moment, we support 1.1.0+ and all are in CI. We fail on 1.0.0, and I'm looking into it. |
I filed #265 to track 1.0.0 support in case that's what we decide to go with. |
As of #444 we support 1.7.0+. We should RFCify our policy before another bump, probably. |
Actually closing this in favour of discussing it on the RFCs repo at nix-rust/rfcs#4. |
I just sent a PR to track stable and beta channels of Rust. This would drop "official" support for 1.1, on the assumption that users are going to track stable.
Thoughts?
The text was updated successfully, but these errors were encountered: