Decide on a rust version support policy

[kamalmarhubi]

Essentially migrate from nix-rust/nix#238.

[Susurrus]

This came up in nix-rust/nix#666, which wants to up the Rust version to 1.15 to use before_exec.

I found this issue and thought it'd be nice to actually state a policy on this. libc has taken to only supporting stable and treating rust version requirements as non-breaking changes. An RFC was proposed in rust-lang/rfcs#1619 that suggested they target the stable - 2 release as their minimum supported version. That should allow people time to upgrade but still allow development to move forward. That RFC wasn't merged, but I kind of like that idea.

Does anyone have some thoughts on this? The minimum supported Rust version has come up in a few crates that I follow and while everyone wants to support older versions, I've never seen a user complain about being stuck on an older version. I think Rust's upgrade story is so nice compared to other languages and their toolchains that it's less of a burden requiring people to upgrade.

cc @asomers

[asomers]

I like the idea of having the same support policy as libc. Consistency is good for our users. It looks like libc now runs Travis on stable and 1.0.0, though they don't do the full CI on 1.0.0. We certainly can't support 1.0.0. stable - 2 sounds like a good compromise to me, absent any other community conventions.

In terms of our other dependencies, bitflags and cfg-if only test on stable. void tests on 1.0.0. So our 1.13.0 builds might suddenly break if we ever upgrade bitflags or cfg-if. But I don't foresee any need to do that anytime soon.

[marmistrz]

stable - 2 sounds good either. Rust is developing rapidly.
But why not update the dependencies if nothing breaks?

[Susurrus]

But why not update the dependencies if nothing breaks?

What do you mean? I don't think we've ever precluded updating our dependencies in this discussion. The comment @asomers was making was that our dependencies don't have the same Rust version guarantees (or at least don't test theirs in CI) we have so it might have issues if we ever need to update our dependency versions.

[marmistrz]

Well, I just meant that we may want to update the things just to get new features or performance improvements.

Anyway, what about the policy? With #666 getting slowly finalized, I need to know if I should uncomment or delete the convenience trait.

[Susurrus]

I'm actually of the opinion that incrementing versions as needed for functionality as we go is the right policy but making it so that we never go past stable - 2. So currently we could bump everything to 1.18 for the next version. I didn't see what version you needed for rust-lang/nix#666, but if it makes the API nicer with minimal downsides besides the version bump then we should do it. I guess I should write this up as a proper RFC.

[marmistrz]

Sounds great! :)
I need 1.15. Should I bump the version in nix-rust/nix#666 on my own?

[Susurrus]

Yes. Bumping Rust versions is just one on a per-PR basis. It'd be good to have the work that requires it as a separate commit if that is easy to read. And be sure to update the README documenting the necessary Rust version!

[asomers]

Upgrading the FreeBSD buildbots can't be done through GitHub, so please open a new issue to upgrade them to Rust 1.15 and assign it to me.