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

So consider this; we have package A (versions A@1.0 and A@1.1) that depends on B (version B@1.0). Now, the author of B has made some breaking changes and decide to release B@2.0. Lets compare “your” approach with “mine”.


With “your” approach, A@1.0 and A@1.1 has no bounds on B at all (because that is “reckless and careless”, and “incorrect”).

Lets first consider the case where B@2.0 does not break our versions of A: Phew, we guessed correctly, thats a relief, our users are safe to pkg> up and get B@2.0 without that breaking anything. Lets hope we are lucky with B@3.0 too.

Now, consider the case where B@2.0 does break our versions of A: Panic mode; quickly add bounds and release A@1.1.1 with correct upper bounds on B. Now our users are safe to pkg> update again. Right?

Well, no, because versions A@1.0 and A@1.1 still claims to support B@2.0, and users might end up with A@1.1.0 and B@2.0: Panic again, what to do? Ah! We can modify the registry and add the bounds we should have had there in the first place! All good!

Again, no, because there is a user that has A@1.1.0 and B@2.0 and everything works perfectly fine; that user happened to not be affected by the breakage. Now, by modifying the registry that user has ended up in an “impossible” state (according to the registry), and that will wreak havoc as soon as that user tries to use the package manager.


With “my” approach, A@1.0 and A@1.1 has bounds on B: since only B@1.0 exist, we require B = "1", since that is what we can verify.

Lets first consider the case where B@2.0 does not break our versions of A: Ah, nice, we can relax the bounds to B = "1,2", and make a new release A@1.1.1. And just to be nice, lets also release A@1.0.1 with the relaxed bound if someone still uses A@1.0.

Now, consider the case where B@2.0 does break our versions of A: Makes sense, B@2.0 is an (according to SemVer) breaking release, and we already have reasonable bounds so nothing to do. Let’s just put on our TODO list to fix A to be compatible with B@2.0.


Why do you prefer your approach here? The only “good” thing I can see with your approach is that it makes it a bit more simple in the (presumably) rare case that we guessed correctly about how breaking the next breaking release of B would be.


Welcome to the club :slightly_smiling_face:

19 Likes