@kristoffer.carlsson Yes, I was replying to you. And I thought your previous comment was a reply to me.
So the core of your post was this then?
I don’t think that is the “correct” behavior. Changing package does not install when another package needs to downgrade · Issue #110 · JuliaLang/Pkg.jl · GitHub seems better to me.
My argument is that introducing upper bounds in General when there is no such declaration in the original REQUIRE files (and not updating them) is wrong.
The sentence you quoted is misleading without the preceding part:
Counterpoint: claiming compatibility with breaking version that doesn’t exist yet is wrong.
1 Like
First of all, I’m not claiming that loose compatibility declaration is the best software practice. I’m talking about the specification of the REQUIRE/Project.toml format and the correctness of the implementation.
Let me ask a genuine question. The documentation of Pkg says
If the compatibility for a dependency is not given, the project is assumed to be compatible with all versions of that dependency.
Does this mean “maximally “semver”-compatible version of the version existed at the time of the registration?” What about the >= specifier? If that’s the case, I think it is better to clarify as such in the documentation.
If that’s not the case, i.e., there is a facility to express “compatible with all versions”, I don’t understand why the information in REQUIRE files is not faithfully translated.
Having said that, I do 100%-agree with
for post-1.0 semver-compatible software. I’m ambivalent about it for pre-1.0.