-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Bump MSRV to 1.70 #11493
Bump MSRV to 1.70 #11493
Conversation
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 7425519547Warning: This coverage report may be inaccurate.We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
💛 - Coveralls |
I put this on hold because we might need to bump to 1.70.0 instead of 1.67.1 for one dependency. |
This commit bumps the minimum supported rust version (MSRV) from 1.64 to 1.70. We're evaluating using new rust libraries in the Qiskit accelerate crate that have MSRVs of 1.70 (the upstream libraries have a higher MSRV primarily because of internal use of generic associated types in those libraries). This commit raises the MSRV proactively to align with the 1.0.0 release so we don't have to raise it during a minor version release (like 1.1.0 or 1.2.0) if we chose to start using the libraries later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to leave us on a lower MSRV than this, given 1.70 is only six months old, but it does look like that'll be more of a problem for the compiler frameworks we're anticipating using in the OQ3 parser, so I'm ok with it.
How strictly are you thinking we should abide by "no MSRV increases during the 1.x series?". I guess the question depends a lot on whether we think 1.2 -> 1.3 in Rust semantic versioning allows an MSRV bump. I've seen arguments from Rust people that it should be allowed, though I'm not entirely convinced. It feels like our main driver for a bump would be major new features in a dependency getting gated behind a higher version, but there doesn't seem to be anything in Rusts 1.71 onwards that would necessitate that for us - likely the biggest change will be the return-position impl Trait
, but that's primarily for async
and the proposed generator stuff, which we aren't using and are unlikely to be.
The language I put in the stability policy docs was:
My thinking was we can bump the MSRV in 1.1, 1.2, etc if there is a good reason to. But in general if we can avoid it then I think that'd be for the best and we should just keep using 1.70 for all of the 1.x series. If we encounter some reason to raise it within the next year we can discuss it at the time. |
Yeah, that's fine by me - we'll aim to keep 1.70 throughout, but not commit to it. |
The recent ahash release 0.8.7 started using the library feature 'stdsimd' which was not stabilized until Rust 1.72 for aarch64 and will cause an issue when building for aarch64 on (see tkaitchuck/aHash#195 for more details) with our MSRV which was 1.64 and was just raised to 1.70 in Qiskit#11493. This isn't caught in CI because we don't have any aarch64 environments to test with. As 1.72 is fairly recent < 6 months old as of this commit. This just opts to pin the ahash version used to one that is compatible with our MSRV on all supported platforms.
The recent ahash release 0.8.7 started using the library feature 'stdsimd' which was not stabilized until Rust 1.72 for aarch64 and will cause an issue when building for aarch64 on (see tkaitchuck/aHash#195 for more details) with our MSRV which was 1.64 and was just raised to 1.70 in Qiskit#11493. This isn't caught in CI because we don't have any aarch64 environments to test with. As 1.72 is fairly recent < 6 months old as of this commit. This just opts to pin the ahash version used to one that is compatible with our MSRV on all supported platforms.
The recent ahash release 0.8.7 started using the library feature 'stdsimd' which was not stabilized until Rust 1.72 for aarch64 and will cause an issue when building for aarch64 on (see tkaitchuck/aHash#195 for more details) with our MSRV which was 1.64 and was just raised to 1.70 in #11493. This isn't caught in CI because we don't have any aarch64 environments to test with. As 1.72 is fairly recent < 6 months old as of this commit. This just opts to pin the ahash version used to one that is compatible with our MSRV on all supported platforms.
This commit bumps the minimum supported rust version (MSRV) from 1.64 to 1.70. We're evaluating using new rust libraries in the Qiskit accelerate crate that have MSRVs of 1.70 (the upstream libraries have a higher MSRV primarily because of internal use of generic associated types in those libraries). This commit raises the MSRV proactively to align with the 1.0.0 release so we don't have to raise it during a minor version release (like 1.1.0 or 1.2.0) if we chose to start using the libraries later.
The recent ahash release 0.8.7 started using the library feature 'stdsimd' which was not stabilized until Rust 1.72 for aarch64 and will cause an issue when building for aarch64 on (see tkaitchuck/aHash#195 for more details) with our MSRV which was 1.64 and was just raised to 1.70 in Qiskit#11493. This isn't caught in CI because we don't have any aarch64 environments to test with. As 1.72 is fairly recent < 6 months old as of this commit. This just opts to pin the ahash version used to one that is compatible with our MSRV on all supported platforms.
Summary
This commit bumps the minimum supported rust version (MSRV) from 1.64 to 1.70. We're evaluating using new rust libraries in the Qiskit accelerate crate that have MSRVs of 1.70 (the upstream libraries have a higher MSRV primarily because of internal use of generic associated types in those libraries). This commit raises the MSRV proactively to align with the 1.0.0 release so we don't have to raise it during a minor version release (like 1.1.0 or 1.2.0) if we chose to start using the libraries later.
Details and comments