Skip to content
This repository has been archived by the owner on Oct 31, 2024. It is now read-only.

Specify MSRV instead of fixing the toolchain #5

Closed
wants to merge 4 commits into from
Closed

Conversation

Nashtare
Copy link
Member

Description

Specifying a rust-toolchain file fixes the Rust version being used, while we should rather specify an MSRV instead, as is the rust-version field of Cargo.toml intended to be.

PR Checklist:

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added or updated tests that comprehensively prove my change is effective or that my feature works

@Nashtare Nashtare self-assigned this Sep 24, 2023
@Nashtare
Copy link
Member Author

I'm not sure why the CI for code-coverage is failing, it shouldn't. The error is the following:

Run cargo tarpaulin --verbose --engine llvm --release --out Xml
error: invalid value 'Xml' for '--out [<FMT>...]'

I've noticed it failing on other repos as well (for instance https://github.com/toposware/cheetah), though not really blocking.

@sebastiendan sebastiendan requested review from Freyskeyd and removed request for sebastiendan September 27, 2023 16:06
@sebastiendan
Copy link
Member

Swapping my review with Simon's as I think he can be of much greater value here

@Nashtare
Copy link
Member Author

@sebastiendan Sure thing! Although the CI check being red is a bit ugly. As we'll publish this on crates.io at some point, we'll probably want to address it soon. But non-blocking for this particular PR.

Copy link
Contributor

@dvdplm dvdplm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting an MSRV without testing it in CI is not very useful. If it's truly meaningful to commit to a MSRV I think the project README should state the policy:

  • how long do we guarantee the current MSRV?
  • backporting policy (we don't backport security patches to the MSRV I'd say, but we should state this publicly)
  • when we update the MSRV, how is this communicated? What is the lead time?

Note that committing to a MSRV means that changing it is a breaking change in semver speak, so it means releasing a new major version.

IMO committing to an MSRV is not something we should take lightly.

@dvdplm
Copy link
Contributor

dvdplm commented Oct 4, 2023

Run cargo tarpaulin --verbose --engine llvm --release --out Xml

Speculation: perhaps it should be --out xml? And it works for macos users because the FS is case insensitive?

@Nashtare
Copy link
Member Author

Nashtare commented Oct 4, 2023

Speculation: perhaps it should be --out xml? And it works for macos users because the FS is case insensitive?

Perhaps, though I'm confused why it was working in the first place then.

Regarding the MSRV comment, I don't really have an objection to not setting a MSRV and just relying on the latest stable, it just felt more proper to have it declared (and I think as a general rule if every crate was specifying their MSRV this would definitely help the ecosystem) but I'll leave the experts decide here 🙂
@Freyskeyd Do you have any opinion?

@Nashtare Nashtare mentioned this pull request Oct 10, 2023
4 tasks
@Nashtare
Copy link
Member Author

Closing in favor of #9.

@Nashtare Nashtare closed this Oct 10, 2023
@Nashtare Nashtare deleted the specify-msrv branch October 11, 2023 15:49
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants