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

**URL:** <https://discourse.julialang.org/t/please-be-mindful-of-version-bounds-and-semantic-versioning-when-tagging-your-packages/30708>\
**Category:** Community\
**Created:** [November 4, 2019, 6:53pm UTC](https://discourse.julialang.org/t/please-be-mindful-of-version-bounds-and-semantic-versioning-when-tagging-your-packages/30708 "2019-11-04T18:53:20Z")\
**Posts on this page:** 1\
**Showing post:** 46

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [November 5, 2019, 8:25am UTC](https://discourse.julialang.org/t/please-be-mindful-of-version-bounds-and-semantic-versioning-when-tagging-your-packages/30708/46 "2019-11-05T08:25:38Z")

</div>

> [@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](https://discourse.julialang.org/t/please-be-mindful-of-version-bounds-and-semantic-versioning-when-tagging-your-packages/30708/29)), 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](https://github.com/JuliaLang/Pkg.jl/issues/819), 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](https://github.com/JuliaLang/Pkg.jl/issues/1062)

---

_[View the full topic](https://discourse.julialang.org/t/please-be-mindful-of-version-bounds-and-semantic-versioning-when-tagging-your-packages/30708)._