Decide on a rust version support policy

[kamalmarhubi]

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?

[carllerche]

I commented on #237 saying that I think 1.3.0 is good for the oldest official Rust support for now.

[kamalmarhubi]

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.)

[carllerche]

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.

[kamalmarhubi]

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.

[fiveop]

I would prefer not to allow failures on nightly. I see three cases why it might fail:

1. We introduced a bug in nix. => We fix it.
2. The language changed in such a way, that our build breaks. => We fix it (if necessary with feature guards).
3. Rust nightly has a bug. => We wait a day or two.

[kamalmarhubi]

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.

[kamalmarhubi]

Or summarising:

We introduced a bug in nix. => We fix it.

We should see it in other releases and fix it.

The language changed in such a way, that our build breaks. => We fix it (if necessary with feature guards).

Shouldn't happen.

Rust nightly has a bug. => We wait a day or two.

Annoying and disruptive. (Subjective, of course.)

[kamalmarhubi]

@arcnmx any thoughts on this? You have some changes in mind that seem to assume bleeding edge rust...

[arcnmx]

I would prefer not to allow failures on nightly.

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 rand crate, and lasted quite a number of days. If we're ever to perhaps start using @homu we may not want to deal with them being hard failures.

any thoughts on this? You have some changes in mind that seem to assume bleeding edge rust...

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.

[kamalmarhubi]

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

[kamalmarhubi]

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.

[kamalmarhubi]

I filed #265 to track 1.0.0 support in case that's what we decide to go with.

[kamalmarhubi]

As of #444 we support 1.7.0+. We should RFCify our policy before another bump, probably.

[kamalmarhubi]

Actually closing this in favour of discussing it on the RFCs repo at nix-rust/rfcs#4.