Dependency problem with FIllArrays

@StefanKarpinski I hope you don’t take my comments as complaint. I think it is a great step forward that the new Pkg.jl is raising awareness of package compatibility in the community by making the semver-based constraint [1] the default behavior in [compat] section.

My question is a rather technical one; i.e., if

is true for gen_project.jl and the current state of General. First of all, I’m supposing that I can replace the word “literally” in your sentence with “semantics-preserving” or “faithful.” I don’t see it how it connects with the next sentence if not.

Isn’t this what is happening here? And isn’t it because Package = "x.y.z" is not semantically equivalent to Package x.y.z? Why it is done this way even though [compat] can represent it as Package = ">= x.y.z"? Or maybe my assumption is wrong because the dependency resolver is changed?

But you also said

So maybe it’s rather a “social” or “pedagogical” issue rather than a technical one? That is to say, the decision was made to give a narrower range of compatibility so that package authors are forced to think about the compatibility issue seriously?

[1] Side note: I’m not sure talking about compatibility in sub-1.0 software is strictly semver compliant. At lease I think the use of Package = ">= 0.y" does not have to be so frowned upon if your package is sub-1.0 as well.

1 Like

I don’t know if it’s damned if do or don’t, but definitely if you do and don’t, especially in a random way. So far we have:

  1. Upper bounds added when moved from METADATA to General
  2. No upper bounds when generating Project.toml from REQUIRE
  3. Upper bounds ignored by Registrator.jl (https://github.com/JuliaLang/Pkg.jl/issues/1177#event-2304129269)

I thought I understood what to do (use MyPackage = "0.3" in a tagged release to only support 0.3.x and retag when MyPackage.jl v0.4 comes out) but now I have no idea what we are supposed to be doin…