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.
Hi,
I'm considering using zip2 in a project that has a downstream pin to
aes =0.8.3
but zip2 requiresaes ^0.8.4
.It seems like your current strategy is to periodically bump dependency versions to the latest versions, even for SemVer-compatible releases. Is this a measure to ensure that security-critical bugfixes are always picked up when using recent versions of zip2? If not: Would you be fine with more relaxed version bounds for zip2's dependencies?
In this PR I've added a CI job that tests the project with the lowest-compatible dependency versions (
cargo update -Zminimal-versions
), bumped an outdated dev-dependency that breaks builds with minimal versions, and relaxed versions of the project's dependencies where appropriate.Feel free to merge or close 🙃
Thanks!