-
-
Notifications
You must be signed in to change notification settings - Fork 29
Commit
toml_edit requires it. ``` error: package `toml_edit v0.19.15` cannot be built because it requires rustc 1.66.0 or newer, while the currently active rustc version is 1.65.0 ```
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
|
@@ -2,7 +2,7 @@ | |||||||
name = "cargo-hack" | ||||||||
version = "0.6.5" | ||||||||
edition = "2021" | ||||||||
rust-version = "1.65" | ||||||||
rust-version = "1.66" | ||||||||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
taiki-e
Author
Owner
|
# There is binary in the workspace, but intentionally not committing lockfile. | |
# See https://github.com/taiki-e/cargo-llvm-cov/pull/152#issuecomment-1107055622 for more. | |
Cargo.lock |
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
epage
Sep 8, 2023
Contributor
I'd recommend reconsidering this
- If anything is yanked, your project can't build
- If you want the MSRV to "never lie" then that is impossible because any time a new dependency comes out, it will then be wrong. MSRV is not about every possible version but that a set of versions exist
- On error, cargo will now recommend using
--locked
which will let people get past other problems which was specifically added to help with MSRV above - We are actively working to improve the MSRV experience
- RenovateBot, while it has its flaws, is a lot better than Dependabot. Check out my configuration for a bin workspace and checkout example PRs
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
taiki-e
Sep 8, 2023
Author
Owner
- If anything is yanked, your project can't build
No. As described in the issue I linked, cargo publishes the lockfile even if it is not committed, so yanking doesn't prevent users from building.
- If you want the MSRV to "never lie" then that is impossible because any time a new dependency comes out, it will then be wrong. MSRV is not about every possible version but that a set of versions exist
Personally, I think MSRV (as documented at the time of release) should be considered the minimum version that can be built when using the latest dependencies at the time of the release of that version.
It's okay to break if a dependency updates MSRV after release (although I need to bump MSRV like in this commit). Users can use --locked
to build with the latest dependencies at the time of the release of that version.
As far as I know, that is the best we can actually guarantee at this time, and I want to guarantee that as much as possible.
Well, as I said in the second issue I linked, this is not best from a maintenance cost point of view, so I wouldn't actively recommend this method to others.
Why not check-in a lockfile?