I would personally prefer a small subset of a package’s new functionality not working to Pkg giving up with “sorry, your package dir is screwed and I refuse to do anything at all.” Maybe that tradeoff doesn’t happen in theory, but right now it does happen in practice.
More generally, it seems that having Pkg be able to resolve arbitrary version requirements consistently requires every author to maintain a correct dependency list of the entire version history. This makes me extremely sceptical that it’s a reasonable goal to have at all.
Usually it’s not a matter of “new functionality not working,” rather it’s “Pkg.update() broke my previously-working code.”
A much easier-on-the-resolver approach would be to use a new package name every time you make breaking changes, but that’s not something a lot of people are likely to do.
I’ve been thinking lately that unless there’s a manually specified upper bound, it should default to the next major version after the lower bound (minor before 1.0).
That is
Foo 0.5.0 means Foo 0.5.0 0.6.0
Foo 3.0.0 means Foo 3.0.0 4.0.0
Also, packages should be encouraged to move to 1.0 once reasonably stable, so better use of SemVer is possible.
It would also be nice if Pkg3 enables multiple copies of a package, one for each major version, to be installed, and picked the appropriate one for each using statement based off the package REQUIRE.
Highly disagree. Packages should try to keep to the latest version whenever possible. Otherwise users will be plagued with having older versions than they realize, and this causes many issues. I would say the majority of “easily closed issues” are users who have problems with the package, only for you to realize it’s because they have an old version. This is already far too common.
Packages should be able to request a lower version number that they can use internally to make sure things don’t break. But users should be presented with the latest versions of the packages they are asking for. If Pkg3 allows for multiple copies of a package, I think that what it should be doing is just making an internal copy of each requirement that has an upper bound.