Skip to content
This repository has been archived by the owner on Feb 28, 2023. It is now read-only.

MSRV policy #88

Closed
Xanewok opened this issue Jul 11, 2021 · 3 comments · Fixed by #118
Closed

MSRV policy #88

Xanewok opened this issue Jul 11, 2021 · 3 comments · Fixed by #118
Labels
question Further information is requested

Comments

@Xanewok
Copy link
Contributor

Xanewok commented Jul 11, 2021

As of writing, we decided to enforce the same CI suite that's used by mozilla/sccache to facilitate possible patch upstreaming. We're using Rust 1.43 (a badge was added in #86) but as we slowly drift away from the upstream, it might be worth revisiting this decision and either come up with our own policy or leave the things as-is for now.

One concrete example where a newer MSRV might help is #84 (comment) (strip_prefix). That's probably not enough of a reason to bump the MSRV and we should gather more cases like that before we decide to do the bump.

@Xanewok Xanewok added the question Further information is requested label Jul 11, 2021
@drahnr
Copy link
Contributor

drahnr commented Jul 12, 2021

There are more cases in the code base, i.e there was custom matches macro which was already in newer stable, which we eventually removed. For the mentioned #84 required an extra roundtrip to ensure compat with 1.43 which now is a bit over a year old.

Given that the defacto standard rustup allows managing toolchains pretty well, I propose to bump the MSRV as needed, but not beyond the previous stable rust version.

@kirushik
Copy link

From the high-level point of view I don't mind if we adopt the same "latest stable Rust only" compilation target policy as we have in other projects in Parity.

I don't think there would be enough value in keeping patch compatibility with upstream sccache after rename/divorce: it seems unlikely that upstream would get to development speed to incorporate our patches any time soon, and bumping Rust version on our side won't stop us from downstreaming some patches if we see the need.
And in longer term our codebase would be drifting further and further from the original sccache, making those patch exchange considerations ever less of a topic.

But of course I might be blind to other reasons to stick to the previous Rust versions aside from that (like, expectations of some other players of note in the ecosystem) — it would help to outline all those in this issue explicitly, so we can contemplate/revisit the list later on.

@drahnr
Copy link
Contributor

drahnr commented Nov 13, 2021

All the discussions so far have pointed out, that there is no good reason to support older rustc version other than the latest stable. #118 addresses this and sets the MSRV to 1.56.1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants