Backpropagate compat bounds

As has been pointed out by @fredrikekre in Please be mindful of version bounds and semantic versioning when tagging your packages - #20 by fredrikekre, compat entries do not backpropagate to older versions of a package.

Say I have a package that has a couple of versions already, all without compat entries (because I didn’t care). Now I add compat entries in the newest version, because I realized that’s what I should do. The resolver might now in case of conflicts fall back to installing an older version of the package because it implicitly claimed compatibility with everything (by not having compats), which is likely wrong.

The question I have is: How do I backpropagate compat entries, such that all older versions of my package get them as well? Do I file a PR against the General registry? What should such a PR look like?

Thanks in advance.
Carsten

2 Likes

You could edit the Compat.toml file. For example, here is Revise’s version of that file: https://github.com/JuliaRegistries/General/blob/master/R/Revise/Compat.toml. You could find every mention of a particular dependency and make sure that the upper bound is below some threshold, or that every release has an upper bound that is at least as low as the release that followed it.

Back in the PkgDev days I wrote this: https://github.com/JuliaLang/PkgDev.jl/pull/94. But the new Pkg makes these kinds of things more straightforward, since you don’t have to open and rewrite a bazillion files.

1 Like

I tried to explain in this comment why I am a bit hesitant to modify the registry.

Basically, relaxing bounds should be safe, but can have non-local effects that you can no predict, and that might also be damaging. Tightening bounds can result in users ending up in an “impossible” state (according to the new registry), which the package manager does not like.

2 Likes

It’s necessary if, for example, we discover that there should have been bounds (but weren’t) on a prior release. That should be less and less common, of course. When I added those facilities to PkgDev, there were very few packages that had upper bounds on anything.

But for ordinary advancement of version numbers, I am increasingly “with you” on the notion that an explicit upgrade on dependent packages is the way to go.

1 Like

Isn’t it still safe to upper bound by the existing upstream versions by the time the bound is added? It may still be inaccurate (i.e., the installation would break) but it would at least constraint the effect of old unbounded releases.

Sure, but then you haven’t really tightened the bound since all package are implicitly bounded by the latest release of its deps.

It would avoid future problems that the resolver tries to fallback older releases that have no bound.

I know, I just meant that since you are not actually tightening the bounds its like a no-op.

Well, it’s better than nothing if you can get rid of the future problems.

Yes, I don’t disagree with you. I’m just saying that its not a problem :slight_smile:

3 Likes

BTW, I think it would be great if the CI verifies that the tightened bounds are indeed “no-op” (at the time of the merge).