Please be mindful of version bounds and semantic versioning when tagging your packages

[fredrikekre]

@chakravala

basically, I only tag releases as a courtesy so that other people with less time on their hands can keep up with my work in computer algebra…

Well, why didn’t you just admit this from the start? That you are only trying to make things easy for yourself instead of pretending you follow a much better path.

Also, you seem to base your reasoning on things that are not correct, e.g. here, where you (seem to?) think that adding bounds to a new release retroactively adds the same bounds on previous releases:

@fredrikekre

You are wrong, I have previously tagged releases in the new registry and have seen what happens.

What happens is that in the registry all previous version get the bounds added. Try it, you’ll see.

Since the registry entries get updated, when somebody updates their registry, they get the bounds.

I’m not wrong.

And also, when presented with an actual example (Please be mindful of version bounds and semantic versioning when tagging your packages - #29 by fredrikekre), you didn’t explain and/or answer how you would solve that problem.

@mohamed82008

This kind of situation can cause long and sometimes unnecessary breakage time if package B did not really break A1 , A3 , A4 , etc. I think a big part of this is psychological, where fixing things because they are broken is seen as time well spent whereas putting in time just to make sure things are still working is seen as a waste of time by some, especially if it could be avoided in those near-miss cases.

But at least there a state that is proven to work. That might not include beeing on the latest version of every dependency, but at least it is something working. The opposite would be that users just get some random version that claims to be compatible with everything.

@mohamed82008

You are assuming that one of the users of my package A1 has enough experience to figure out that the compat of B in A1 needs to be bumped up, and then made a PR. I think this assumption is only true for a relatively small subset of core packages and other lucky packages that are used by Julia programmers who know what they are doing. Even figuring this out might be a difficult task for good Julia programmers who are not familiar with the code base of A1 , and then there is A3 , A4 , etc. also to check.

Okay, so say I am completely new user and know nothing about versions etc. I decide to test out some of these packages: pkg> add A1 A2 B, and I get, say, A1@1, A2A1@2, BA1@3. Cool! I can start writing Julia code now!
Turns out there exist A1@2, which I am happily unaware of. Now, if it turns out I do need A1@2, I try to add it and get a resolver error message (admittedly these can be better, see Better resolver failure messages · Issue #819 · JuliaLang/Pkg.jl · GitHub, but at least I have something to report). So since I am a new user and don’t understand why, I raise an issue with A1: Hey, why can I now use A1@2 here?. Hopefully it is still a maintained package, and the problem can be resolved.

Consider now the case with no bounds; I try again pkg> add A1 A2 B, but this time I get A1@2, A2A1@2, BA1@3. I start writing code, nothing works.
As a new user, where do I raise an issue? I don’t know. Lets file an issue with A1. What do you as a maintainer of A1 tell this user? What versions of the dependencies do you have? Well, I just use what I got from the resolver, that you as the maintainer told the registry you were compatible with. Ok, but I just hoped nothing would break. You need to add this package at that version, and that other package on that version. Can you try that?

That does not seem more user-friendly to me.

---

@mcabbott

When trying to add [compat] section, it’s hard to know what lower bounds to put. A much earlier version of some package you use very little of may well be fine. Should there be a Pkg.down command that does the opposite of up , so that you can test there, and figure out generous lower bounds?

Yea, but putting the latest (SemVer) breaking release there is never wrong, after all, it is unlikely that your package works with more than one or two breaking versions of your dependency, so it is not that hard to test. If you (or your users) feels it is important that the package also work with older releases of that dependency they can fix that. See also Introduce `down` as opposite of `up` · Issue #1062 · JuliaLang/Pkg.jl · GitHub