Minimum-Supported-Version (MSV) strategy for dependency version

tools and infrastructure cargo
1

Example:

[dependencies]
some-crate = { minimum = "1.0.0" }

Why not version = "^1.0.0"?

  1. some-crate release version 2 and 3, but our crate still supports version 1.
  2. Maintaining costs.

What should we do when some-crate released incompatible version?

For example, assume it released incompatible "1.2.3", Then we should release a patch version for our package with considering one of these scenarios:

  • If they didn't still fix incompatibility, we should use maximum:
    [dependencies]
some-crate = { minimum = "1.0.0", maximum = "1.2.3" }
  • They fixed incompatibility in "1.5.0", we should use conflict:
    [dependencies]
some-crate = { minimum = "1.0.0", conflict = "~1.2.3, ~1.3, ~1.4" }

Notes

  • minimum, maximum and conflict could have better naming.
  • minimum and maximum don't accept version specifiers (e.g. ">=")
  • conflict only supports , and ^. perhaps special range could be added here (e.g. 1.2.3..1.5)
  • It is more readable than version-specifiers in my POV.

This idea actually inspired by Consider removing upper bounds on dependencies · Issue #406 · openlawlibrary/pygls · GitHub

I'll be happy to see your comments.

I didn't find the best equality of { minimum = "1.0.0", conflict = "~1.2.3, ~1.3, ~1.4" } in version specifiers. WDYT?

2

This goes into a solution without giving context of what problem you are trying to solve.

It is hard to compare ecosystems because Python has less of a culture around semver.

A major challenge with this is that cargo always picks the latest version when a dependency is added. If that newest version is incompatible then it requires you to patch to avoid breaking people as compared to now where it just works.

Also when you are dealing with "public" dependencies, the newest version of a package might not work for you but might work for a peer and then things get complicated. Some of us deal with this today when dealing with -sys packages like git2 because most breaking changes don't affect our packages but only being able to have one copy of git2 in the dependency tree is annoying, so we tend to do version ranges that cover multiple semver versions. This can lead to cargo picking mismatching versions of things.

3

Yes, absolutely you are right, since Rust can have multiple versions of a package, but Python cannot, so at there, version conflicts are important.

Since Python only accepts version specifiers in its standard, and when I didn't find equality of { minimum = "1.0.0", conflict = "~1.2.3, ~1.3, ~1.4" } with version specifiers, I thought it's good to share this idea where it could be implementable.

Edit: I opened a discussion in python-poetry, you can close this topic.

4

New Pythonic proposal of this now available in Minimum-Supported-Version (MSV) strategy for dependency version - Packaging - Discussions on Python.org

I'll be happy to hear your comments at there <3