Pin deps #73
Merged
Pin deps #73
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(This PR is dependent upon #72. Only the last commit in this PR does the thing.)
This does not change the version of any of the dependencies as they would be resolved in a fresh repo now. it does avoid newly published versions of upstream crates breaking things, like changing the generated files in prost-build or updating performance characteristics without changing the api.
Just as importantly, this actually causes the contents of Cargo.toml to accurately reflect the versions of the dependencies that are resolved, which shows some some pretty significant drift in the version numbers in a lot of these cases.
Probably the best way to check for outdated dependencies here is
cargo oudated --depth 1, with "cargo-outdated" installed. Performing that task before updating the benchmarks seems like a reasonable addition to the workflow and can make tracking the provenance of these performance numbers a lot easier.Of course the goal here is to make maintaining and updating the repo and tracking what's going on with it easier, and if you as the maintainer don't think it serves that purpose then 🤷♀️ 🚮 😄. I just reckon this seems like a probable improvement.