paritytech / cachepot

cachepot is `sccache` with extra sec, which in turn is `ccache` with cloud storage
https://cachepot.cc
Apache License 2.0
171 stars 13 forks source link

MSRV policy #88

Closed Xanewok closed 2 years ago

Xanewok commented 3 years ago

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 https://github.com/paritytech/sccache/pull/84#discussion_r667478598 (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.

drahnr commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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