I’ve never understood why this rule is enforced in the General registry, e.g. here. If a package changes in no other way than narrowing supported versions of Julia, that is to say that no new functionality is introduced nor is old functionality is changed, then it seems like Semantic Versioning has very little to say about whether the new version should be a major, minor, or patch version. In fact the SemVer spec has a section about this very case which says that either the minor or the patch version can be changed.
Isn’t it the job of the package manager to figure out whether a package version is compatible with your other packages, and current version of Julia? Why force minor version increments when no new functionality was added?
The idea is that you should still be able to make patch releases to the version compatible with the previous Julia version. For example: Package A@1.2.0 is compatible with Julia 1.0 (current LTS). If you release A@1.2.1 with Julia compatibility raised to 1.5 for example, what do you do when a user stuck on Julia 1.0 finds a bug in A@1.2.0? The 1.2.1 version number needs to be reserved for that case.
Edit: Just to add to the above; the package manager handles it just fine, so this is just a policy for the General registry that is meant to stop package authors from shooting themself in the foot like in the example I gave.
7 Likes
Ah I see, that makes sense! Thank you!
So is this rule also applied to all other dependencies of a project? It seems like a user could also be stuck on a particular version of other packages, and experience the same problem you outlined in your answer.
just to note that it is an “automerge guideline”, not a rule of the General registry. The difference being you only need to follow it for your updates to be automatically accepted but they can still be manually accepted if the rule is not followed. So it’s not saying “this is how you must do it”, but rather “this is the most uncontroversial way to do it and so qualifies for merging without any further discussion”.
It is not enforced by the registry automerge guidelines.
I guess it might make sense to not bump a dependency to a new major version in a patch release? For example, if your package A with B@1 as a dependency goes to B@2, maybe that shouldn’t be done in a patch release? I have not thought about it much actually. Typically for packages users are always at the latest version of everything so this has not really been “tested” in practice. It is also the case that packages aren’t as structured as Julia when it comes to releases/LTS versions etc, so I assume many package authors just declare B@1 to be unmaintained as soon as B@2 is out.
If package authors were careful with not releasing “breaking” versions that don’t break it might be good practice to recommend that if you raise the compatibility for a dependency you should release a minor version.
3 Likes
I wonder how long this will continue to be true. I’ve recently run into problems with not being able to update to the most recent versions of packages, because other packages that I use have not been updated in a year or two and impose upper bounds on a mutual dependency of the two packages. I’m just glad that none of the packages that I use have vanished, or have been abandoned (yet!).
Anyways, thanks for the answers, I really appreciate it!
Often, but not always, this is a result of package authors releasing “breaking” versions that is not actually breaking. This messes up compatibility bounds for all packages that depend on it.
1 Like
In this case it was because of Compat.jl, and some packages trying to maintain support for pre 1.0 versions of Julia. But yeah, I’m very glad that CompatHelper.jl works as well as it does, without it it seems like keeping up with new major versions of packages (warranted or not) would be very difficult.
Yea. Perhaps a good recommendation is that going from
[compat]
B = "1"
to
[compat]
B = "1, 2"
is fine in a patch release, since it does not impose any new restrictions, but going from
[compat]
B = "1, 2"
to
[compat]
B = "2"
should be done in a minor release since the new version will not be compatible with B@1 anymore.