Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate dependency version ranges to maximise compatibility #653

Open
Xophmeister opened this issue Nov 13, 2023 · 3 comments
Open

Investigate dependency version ranges to maximise compatibility #653

Xophmeister opened this issue Nov 13, 2023 · 3 comments

Comments

@Xophmeister
Copy link
Member

(Discussed with @Niols during the Topiary weekly.)

Is your feature request related to a problem? Please describe.
Currently, the dependencies used by Topiary are pinned to specific versions (or, at least, minor versions). Often, during development, those versions are bumped in the Cargo.lock. When distributing Topiary, to enable building on the widest range of targets as possible, it would make sense to allow a range of versions for each dependency.

(n.b.: Dependencies include the Rust toolchain.)

Describe the solution you'd like
The easiest thing to do, rather than investigating all combinations of dependency versions is to pick a point that is the "minimum" set of dependency versions for the range. Thereafter, the range could be extended into newer versions of each dependency.

A scheduled CI job could be created to check that the minimum and maximum sets still build correctly.

Additional context
Once a range is established, care should be taken when developing new PRs; especially those that introduce new dependencies or extend existing dependencies' ranges.

@torhovland
Copy link
Member

It's an interesting challenge. The flip side is that you do want to stay on top of changes in dependencies, to keep the code base maintainable.

@Xophmeister
Copy link
Member Author

Indeed; at some point those minimum versions may have to be bumped to unlock necessary features/bug fixes.

@torhovland
Copy link
Member

Yes, but it's not just about necessary features and fixes. It's also about staying on top of breaking changes in new versions, so we don't get stuck in a technical debt hole with dependency versions that are no longer managed and can no longer be upgraded easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants