One of our dependencies recently bumped its rust-version causing our MSRV test to break again. It is undesired to randomly work around this by bumping our MSRV, or consistently have PRs/merges fail for unrelated reasons.
Instead, perform the MSRV-test with -Zminimal-versions. This seems to be generally accepted in the Rust ecosystem (as there is otherwise no way for crates to bump MSRV barring a semver-breaking release) and prevents us from hitting unnecessary MSRV build failures caused by dependencies.
At the same time our minimal version bounds are now exercised, ensuring downstream crates depending on the ndk can build with -Zminimal-versions too - which required specifying a few patch bounds for our dependencies.
Unfortunately GitHub's UI for continue-on-error: true doesn't make it obvious that a step/job really didn't succeed, this is only visible from the annotations. Still, it is relevant to keep track of whether our non-minimal-versions build adheres to MSRV.
One of our dependencies recently bumped its
rust-versioncausing our MSRV test to break again. It is undesired to randomly work around this by bumping our MSRV, or consistently have PRs/merges fail for unrelated reasons.Instead, perform the MSRV-test with
-Zminimal-versions. This seems to be generally accepted in the Rust ecosystem (as there is otherwise no way for crates to bump MSRV barring a semver-breaking release) and prevents us from hitting unnecessary MSRV build failures caused by dependencies.At the same time our minimal version bounds are now exercised, ensuring downstream crates depending on the
ndkcan build with-Zminimal-versionstoo - which required specifying a few patch bounds for our dependencies.Unfortunately GitHub's UI for
continue-on-error: truedoesn't make it obvious that a step/job really didn't succeed, this is only visible from the annotations. Still, it is relevant to keep track of whether our non-minimal-versionsbuild adheres to MSRV.