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

[fredrikekre]

@mcabbott

Is there a way to specify all versions in a range, like 0.2 <= v < 1.0 ? I find the docs here baffling (is "0.2" different from "^0.2" ?) but I begin to think they are telling me I must write them all out, "0.2, 0.3, 0.4, ..." by hand?

Since we (Pkg) consider minor versions breaking pre 1.0 there is not really a point in beeing able to specify 0.2 <= v < 1.0.

@chakravala

For example, it is incorrect to specify upper bounds for dependencies until it is known at what version number there will actually be a compatibility issue.

It is correct by definition; we have to assume that the next breaking (according to semver) release is actually breaking.

@chakravala

This cannot be predicted until it happens.

Exactly. So why YOLO it? It’s like not putting on your safety belt when driving because “How can I know I will crash and die otherwise on this new route?”. Thats not what you do; you put on your safety belt, and then if it turns out that specific route is safe, then you can relax. But there is NO way you can know in advance.

@chakravala

For example, I will not be using the auto-merging on any of my packages, because I refuse to specify any upper bounds for dependencies unless I actually anticipate an incompatibility.

… So you are telling me you will go back and edit all your previous releases?

@chakravala

No, you are wrong about your statement. I am strictly adhering to the semantic versioning in fact.

If you are, then whats the problem of adding the bounds?

@chakravala

Just because there is a breaking change in a new release doesn’t mean that my package, which depends on that new release, will be affected. So it could be that you made a breaking change, but my package is not at all affected by it. This is why it is incorrect to require upper bounds in all cases.

It is not incorrect. At the time of the release it is the most correct thing to do, you can not verify that the next release will not break. The only logical assumption, however, is that it indeed will break things.

---

The only logical thing here is to assume that the next breaking (according to the semver version) release is actually breaking. If it turns out that it isn’t, then we can relax the bounds. This way we don’t need to deal with things like this: Put an upper bound on HTTP version in Coverage <= v0.8.0 by martinholters · Pull Request #21711 · JuliaLang/METADATA.jl · GitHub, add upper bound to widgets dependency by piever · Pull Request #21178 · JuliaLang/METADATA.jl · GitHub, Upper bound NNlib for CuArrays by MikeInnes · Pull Request #20147 · JuliaLang/METADATA.jl · GitHub, Upper bound MatrixDepot in LightGraphsExtras by andreasnoack · Pull Request #19874 · JuliaLang/METADATA.jl · GitHub, BlockBandedMatrices upper bound by dlfivefifty · Pull Request #19766 · JuliaLang/METADATA.jl · GitHub, Upper-bound StaticArrays for BEAST by timholy · Pull Request #19688 · JuliaLang/METADATA.jl · GitHub (and Pull requests · JuliaLang/METADATA.jl · GitHub for more).