As Semantic Versioning (and common sense) declares - the major version is incremented in case if non backward compatible change is introduced.
Now let's assume we have a project called Project
that has a current version 1.0.42
and a library Lib
it depends on that is of a 2.1.3
version at the moment.
Does that mean that following semver ideology we should constraint the dependency of the Project
to be Depends: Lib (< 3)
?
From my experience - no one does that, but I find it semantically correct and very self-descriptive.
What do you think of this?
1 Answer 1
The RubyGems package management system has the pessimistic version constraint for precisely this reason:
~> 1.2.3
means "chop off the last component of the version number and treat it is a wildcard, but don't use a version less than specified", IOW
~> 1.2.3
means
1.2.* && >= 1.2.3
and
~> 1.2.3.4
means
1.2.3.* && >= 1.2.3.4
In other words, it means: any version at least as new as the one that was specified, but only within the same "category". So, if you specify a bugfix release, you will get newer bugfix releases but no new minor version. If you specify a minor verso, you will get newer minor versions but no new major version.
Explore related questions
See similar questions with these tags.
Lib (>= 2.x, < 3)
where x is the minor version that introduced the latest feature you rely on (perhaps a patch version too if you depend on a recent bug fix) would be safer, as it rules out 2.(x-1) which your code wouldn't work with.Project
, does the fact thatLib
has version2.1.3
guarantee you that the authors ofLib
strictly follow semantic versioning? Perhaps they don't and remove a function in version2.2
.