-
Notifications
You must be signed in to change notification settings - Fork 77
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
Distinguish between MSRV and minimum *working* Rust version #807
Comments
joshlf
added a commit
that referenced
this issue
Jan 23, 2024
MWRV stands for "minimum working Rust version" (a term we invent here). It is the minimum version of the toolchain that we test with in CI. We maintain (and test) the invariant that MSRV >= MWRV so that we know at all times that our code is compatible with our published MSRV. The reason for doing this is so that we can make progress towards lowering our MSRV without painting ourselves into a corner. We treat MSRV bumps as breaking changes, so if we were to publish a particular MSRV and then later discover a problem, we wouldn't be able to revert to a previously-published, higher MSRV. By tracking MWRV separately, we can ensure that we're making progress while still leaving ourselves wiggle room to revert changes so long as those reversions are compatible with our published MSRV. Once we have let a particular MWRV bake long enough, we can lower the published MSRV to match. Closes #807
joshlf
added a commit
that referenced
this issue
Jan 23, 2024
MWRV stands for "minimum working Rust version" (a term we invent here). It is the minimum version of the toolchain that we test with in CI. We maintain (and test) the invariant that MSRV >= MWRV so that we know at all times that our code is compatible with our published MSRV. The reason for doing this is so that we can make progress towards lowering our MSRV without painting ourselves into a corner. We treat MSRV bumps as breaking changes, so if we were to publish a particular MSRV and then later discover a problem, we wouldn't be able to revert to a previously-published, higher MSRV. By tracking MWRV separately, we can ensure that we're making progress while still leaving ourselves wiggle room to revert changes so long as those reversions are compatible with our published MSRV. Once we have let a particular MWRV bake long enough, we can lower the published MSRV to match. Closes #807
joshlf
added a commit
that referenced
this issue
Jan 23, 2024
MWRV stands for "minimum working Rust version" (a term we invent here). It is the minimum version of the toolchain that we test with in CI. We maintain (and test) the invariant that MSRV >= MWRV so that we know at all times that our code is compatible with our published MSRV. The reason for doing this is so that we can make progress towards lowering our MSRV without painting ourselves into a corner. We treat MSRV bumps as breaking changes, so if we were to publish a particular MSRV and then later discover a problem, we wouldn't be able to revert to a previously-published, higher MSRV. By tracking MWRV separately, we can ensure that we're making progress while still leaving ourselves wiggle room to revert changes so long as those reversions are compatible with our published MSRV. Once we have let a particular MWRV bake long enough, we can lower the published MSRV to match. Closes #807
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 23, 2024
MWRV stands for "minimum working Rust version" (a term we invent here). It is the minimum version of the toolchain that we test with in CI. We maintain (and test) the invariant that MSRV >= MWRV so that we know at all times that our code is compatible with our published MSRV. The reason for doing this is so that we can make progress towards lowering our MSRV without painting ourselves into a corner. We treat MSRV bumps as breaking changes, so if we were to publish a particular MSRV and then later discover a problem, we wouldn't be able to revert to a previously-published, higher MSRV. By tracking MWRV separately, we can ensure that we're making progress while still leaving ourselves wiggle room to revert changes so long as those reversions are compatible with our published MSRV. Once we have let a particular MWRV bake long enough, we can lower the published MSRV to match. Closes #807
Reopening per #811. |
joshlf
added a commit
that referenced
this issue
Feb 10, 2024
MWRV stands for "minimum working Rust version" (a term we invent here). It is the minimum version of the toolchain that we test with in CI. We maintain (and test) the invariant that MSRV >= MWRV so that we know at all times that our code is compatible with our published MSRV. The reason for doing this is so that we can make progress towards lowering our MSRV without painting ourselves into a corner. We treat MSRV bumps as breaking changes, so if we were to publish a particular MSRV and then later discover a problem, we wouldn't be able to revert to a previously-published, higher MSRV. By tracking MWRV separately, we can ensure that we're making progress while still leaving ourselves wiggle room to revert changes so long as those reversions are compatible with our published MSRV. Once we have let a particular MWRV bake long enough, we can lower the published MSRV to match. Closes #807
joshlf
added a commit
that referenced
this issue
Feb 10, 2024
MWRV stands for "minimum working Rust version" (a term we invent here). It is the minimum version of the toolchain that we test with in CI. We maintain (and test) the invariant that MSRV >= MWRV so that we know at all times that our code is compatible with our published MSRV. The reason for doing this is so that we can make progress towards lowering our MSRV without painting ourselves into a corner. We treat MSRV bumps as breaking changes, so if we were to publish a particular MSRV and then later discover a problem, we wouldn't be able to revert to a previously-published, higher MSRV. By tracking MWRV separately, we can ensure that we're making progress while still leaving ourselves wiggle room to revert changes so long as those reversions are compatible with our published MSRV. Once we have let a particular MWRV bake long enough, we can lower the published MSRV to match. Closes #807
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With #791, we have the opportunity to decrease our MSRV to as low as 1.58. For 0.8's initial release, we should not target an MSRV this low. Our current policy is to treat MSRV increases as a breaking changes. Since breaking changes should be infrequent, we should be careful not to back ourselves into a corner where our MSRV blocks us from providing vital functionality in a timely fashion.
Nonetheless, we should still strive for zerocopy to work on old as a Rust version as possible. To facilitate this, I propose that we distinguish between MSRV and Minimum Working Rust Version (MWRV). Our MSRV, encoded in the
rust-version
field of ourCargo.toml
should remain at ~1.60 and decremented cautiously. Our MWRV, encodedpackage.metadata.ci
inCargo.toml
should be as low as technically possible at all times. We should modify our CI to test on MWRV, instead of MSRV, and additionally check that MWRV <= MSRV.The text was updated successfully, but these errors were encountered: