You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the things I've found frustrating trying to update dependencies in my own projects (and 3rd party ones) is keeping the dependency tree free of duplicate copies of the same crate at different pinned versions. This is a notable problem for this crate in particular because it has been a number of deepnesses pinned to exact patch versions and is frequently found in conjunction with other crates that do the same. An example of this is Typst (which uses rustybuzz directly) where it depends on resvg, which in turn depends on RustyBuzz and ttf-parser as well.
I propose relaxing the main manifest to only define dependencies at the minor version level. This will make downstream dependency trees quite a bit easier to manage and allow more frequent version bumps for some projects without bloating the build tree.
In the mean time we still have a tracked lock manifest with exact patch versions for what we have most recently tested and released.
I thought that even if you specify the minor verison in Cargo.toml, as long as you don't specify the dependency with = the minor version won't be pinned? But if that's not the case, I'm fine with this change.
as long as you don't specify the dependency with = the minor version won't be pinned
True, but the default caret requirements syntax allows semver compatible updates. If you specify 1.2.3 it is allowed to update to any 1.2.x release. If you specify 1.2 then it is allowed to update to any 1.x release. Relaxing our dependencies from patch level updates to minor version level is what this PR is about. This should be fine as long as no dependencies start outputting semver-breaking changes in non-breaking releases. In that case all bets are kind of off anyway, and it could just as easily happen in a patch release too.
Re-reading my initial message it looks like I worded the rational quite poorly, sorry for the confusion. The idea is to allow minor version bumps and only block major versions that are expected to be breaking.
This file contains hidden or 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
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.
One of the things I've found frustrating trying to update dependencies in my own projects (and 3rd party ones) is keeping the dependency tree free of duplicate copies of the same crate at different pinned versions. This is a notable problem for this crate in particular because it has been a number of deepnesses pinned to exact patch versions and is frequently found in conjunction with other crates that do the same. An example of this is Typst (which uses rustybuzz directly) where it depends on resvg, which in turn depends on RustyBuzz and ttf-parser as well.
I propose relaxing the main manifest to only define dependencies at the minor version level. This will make downstream dependency trees quite a bit easier to manage and allow more frequent version bumps for some projects without bloating the build tree.
In the mean time we still have a tracked lock manifest with exact patch versions for what we have most recently tested and released.
Any feelings on this guys?