MSRV policy #304
MSRV policy #304
Conversation
closes #285
japaric
added
needs-decision
|
Previous discussion: #285 |
| crate is (post-)1.0. | ||
|
|
||
| - Cargo features are allowed to depend a on Rust version greater than the MSRV, | ||
| even a nightly compiler. For example, a "const-fn" can bump the required |
There was a problem hiding this comment.
I think this is a little confusing. I suspect the intention is to allow something like configs which include code that depends on nightly features, since those configs are not necessarily available for stable. Is this correct?
If so, I think some rephrasing is needed.
There was a problem hiding this comment.
What do you mean by 'configs' exactly? I think as-written it's OK, it's talking specifically about features which we'd allow to require more recent Rust versions since they're so commonly used to test or support new compiler features.
There was a problem hiding this comment.
I was thinking of #[cfg] and associated macro https://doc.rust-lang.org/std/macro.cfg.html
|
I agree with @eddyp comments, else it LGTM |
|
I also agree with @eddyp 's comments, else it LGTM |
|
|
||
| - Changing the MSRV of a crate is a breaking change and requires a semver bump: | ||
| minor version bump if the crate is pre-1.0 and a major version bump if the | ||
| crate is (post-)1.0. |
There was a problem hiding this comment.
One problem I have run into with several crates where I setup CI for a given MSRV over time is that even if nothing changes in the crate itself to break the MSRV when CI builds the project it uses the latest version of dependencies matching the Cargo.toml specifications as the project does not include one (as it is not an "application" itself).
Obviously, if every crate in the dependency chain followed this rule there is no problem (perhaps a good reason to keep deps to a minimum for central crates) but for a few of the Linux crates which have a few more dependencies I have run into this situation due to crates like nix violating this rule. I guess the only solution in that case would be to use the version controls to enforce a < requirement.
Probably the only good solution to this problem is to get consensus throughout the rust community that an MSRV change is breaking.
|
Current votes: 2 registered via GH (@Disasm @posborne) + 1 mine + 1 stale (@therealprof) + 2 in the comments (@korken89 @thejpster) = 7 / 27. |
There was a problem hiding this comment.
I'm very much in favor of not updating the MSRV until necessary (i.e. other changes/refactoring makes updating the MSRV logical), but having recently bumped old codebases I also appreciate the ability to use new Rust language features. Basically, so long as the MSRV is explicit and breaking I am all-in.
japaric
added
decision-accepted
|
Huzza! This RFC has received enough votes (9 registered + 1 mine of the required 33%) to be accepted. Teams please start updating the crate level docs of your crates to indicate the MSRV. bors + |
|
hmm bors r+ |
304: MSRV policy r=japaric a=japaric closes #285 Co-authored-by: Jorge Aparicio <[email protected]>
Build succeeded |
|
Two notes:
|
|
It's not clear what should be done in the first case: the problem should be fixed somehow with patch version bump in order to preserve old MSRV. |
closes #285