Do or not do major-major revisions

[phadej]

E.g. in #373 @andreasabel made major-major revision, i.e. https://hackage.haskell.org/package/slist-0.2.1.0/revisions/

->=4.10.1.0 && <4.18
+>=4.10.1.0 && <5

I don't like that practice. I hope that @andreasabel (or whoever does similar revisions as a Hackage Trustee) puts these packages on their own watch list, so when next major base, containers, hedgehog etc is released they check that the package still compiles fine, and make correcting revisions in case it's not fine ASAP, perfectly before anyone notices.

[phadej]

In particular, in this case looks like Andreas "took over" bounds maintenership of some Kowainik packages (slist, colourista, trial which are dependencies of stan (and nothing else). It would be healthier if @tomjaguarpaw took over these packages if he is the new maintainer of stan, or worked on dropping these (unmaintained?) dependencies from stan.

[phadej]

In particular our policy says (related to relaxing revisions)

Trustees are expected to use this power judiciously and make sure they understand the packages involved and their APIs.

I'd expect the understanding be thoughtful if such super-major relaxations are made.

[endgame]

I disagree with base <5 in revisions for the same reasons that I disagree with it in package uploads: it allows new versions which have explicit permission to make breaking changes.

[tomjaguarpaw]

For the record, I have requested co-maintainership of the entire Kowaink ecosystem, but only been granted maintainership of stan.

[andreasabel]

When you are placing an upper bound, you are making a bet either way.

1. If you place a tight upper bound, like <4.20, you are betting that the package will break when 4.20 comes out. (Pessimistic view.)
2. If you place a loose upper bound, like <5, you are betting that the package will work when 4.20 comes out, and also with 4.21 and maybe with 4.22 etc. (Optimistic view.)

In my limited experience so far, I found that the optimistic view is more "correct" for stable packages in the sense that I bet correctly most of the time, while more caution is required for unstable or feature-rich packages.

One should also look at the damage caused by either way of placing the upper bound.

1. A tight upper bound that is not diligently updated will cause the package to be stuck in the past render the package unusable (or at least hard to use) by others. Often there is no material reason for the tight upper bound, i.e., the package turns out to work the same for many major bumps of its dependencies. The package needs a revision to get unstuck.
2. A loose upper bound that loses the bet leads to compilation errors, forcing users to investigate what the reason of the breakage is. The package needs a revision, and often previous versions of it. The latter is what lay maintainer often forget.

Either way, an upper bound that does not reflect the truth causes damage.
Either way, the package needs attentive maintainership.
The question is how to minimize the work and the damage.

For stable packages, my own resolution is that the optimistic strategy has an overall better performance.

[phadej]

If you place a tight upper bound, like <4.20, you are betting that the package will break when 4.20 comes out. (Pessimistic view.)

It's not betting, it's playing by the rules (of PVP).

That is not pessimistic. It's realistic. PVP doesn't give more guarantees. Maybe CLC will suddenly change their stance and start making vast changes to base (say, a miracle refactoring tool appears which would allow migrating code swiftly, as long as someone migrates it).

For stable packages, my own resolution is that the optimistic strategy has an overall better performance.

That's non-sense.

base <5 bounds are meaningless, there are no widely agreed semantics to < super bounds (PVP doesn't mention any). You can as well put something random like base <4.24 or base <100. It is silly that Cabal / Hackage force you to put some base bound, where you really want to not have any.

Once a revision to package-version had made by Hackage Trustee, the responsibility of keeping that package building is on all of Hackage Trustees.

You can make them as individual to packages you (co-) maintain, say Agda or cassava. But I don't want Hackage Trustees making such revisions as Hackage Trustees.

If you don't feel comfortable leaving the upper bound out completely, don't make major-major relaxations either.

[davean]

There is no bet, you're saying it's unknown. It is in fact unknown.

…

On Sun, Oct 15, 2023 at 9:52 PM Oleg Grenrus ***@***.***> wrote: If you place a tight upper bound, like <4.20, you are betting that the package will break when 4.20 comes out. (Pessimistic view.) It's not betting, it's playing by the rules (of PVP). That is not pessimistic. It's realistic. PVP doesn't give any other guarantees. Maybe CLC will suddenly change their stance and start making vast changes to base (say, a miracle refactoring tool appears which would allow migrating code swiftly, as long as someone migrates it). For stable packages, my own resolution is that the optimistic strategy has an overall better performance. That's non-sense. base <5 bounds are *meaningless*, there are no widely agreed semantics to < super bounds (PVP doesn't mention any). You can as well put something random like base <4.24 or base <100. It is silly that Cabal / Hackage force you to put *some* base bound, where you really want to not have any. Once a revision to package-version had made by *Hackage Trustee*, the responsibility of keeping that package building is *on all of Hackage Trustees*. You can make them as individual to packages you (co-) maintain, say Agda or cassava. But I don't want Hackage Trustees making such revisions as Hackage Trustees. If you don't feel comfortable leaving the upper bound out completely, don't make major-major relaxations either. — Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZLS5TG5XKJB34VJVR5BTX7SHNPAVCNFSM6AAAAAA6ASKXRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGYYDMNJYHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gbaz]

Oleg's right here. We can make our own choices for our own packages, though there's good arguments for tight bounds regardless. However, for trustee revisions, trustee policies dictate that tight and not speculative bounds be used.

[ivanperez-keera]

I have to agree with @phadej here. Revising the package to use base < 5 is not conformant with PVP and I'd be unhappy if my package was revised to introduce that change.

[hasufell]

Revising the package to use base < 5 is not conformant with PVP

I disagree. As usual, the PVP spec is not well worded.

The relevant section is here:

When publishing a Cabal package, you SHALL ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, but also upper bounds on every dependency.

So "accurate dependencies" as per the spec just means "has lower and upper bounds". It doesn't say it must be tight bounds. In fact, it says later that even tight bounds can break compilation:

To minimize breakage when new package versions are released, you can use dependencies that are insensitive to minor version changes (e.g. foo >= 1.2.1 && < 1.3). However, note that this approach is slightly risky: when a package exports more things than before, there is a chance that your code will fail to compile due to new name-clash errors.

Note the wording "you can". So this is not a requirement.

I can't comment on the hackage trustee policy part.

[juhp]

Maybe CLC will suddenly change their stance and start making vast changes to base (say, a miracle refactoring tool appears which would allow migrating code swiftly, as long as someone migrates it).

That should then be base >= 5 in my opinion.

For stable packages, my own resolution is that the optimistic strategy has an overall better performance.

I agree with Andreas

Tightening loose bounds is easier than loosening overtight ones.

Overtight bounds prevent building packages that legitimately can build, just because they might not...

[hasufell]

Also note that CLC requires impact assessments and I believe these would (at least partly) catch issues with too loose upper bounds.

This is the way: testing reverse dependencies and then notifying maintainers of upcoming issues instead of specifying pessimistic upper bounds.

But hackage doesn't facilitate this workflow.

So this really boils down to social trust, policies of individual maintainers and off-hackage communication. This is why I believe enforcing upper bounds is a misguided attempt at fixing a much larger issue.

[ivanperez-keera]

Overtight bounds prevent building packages that legitimately can build, just because they might not...

Overtight bounds pass the responsibility of checking the work on the developer of the package in question.

There's a chance, however slim, that a function might change its meaning between majors without altering its signature. A package that depends on such a function may therefore build, giving a false sense of being compatible with a version of base, when in reality it behaves incorrectly. Such errors may be very tricky to detect.

I think there're better approaches at helping package devs coordinate with GHC devs so that they quickly release new versions of their respective libraries after a GHC release.

[hasufell]

I think there're better approaches at helping package devs coordinate with GHC devs so that they quickly release new versions of their respective libraries after a GHC release.

Yes, instead of shoving everything into head.hackage for no one to know, maintainers could actually be notified. But we're digressing.

Either way is perfectly PVP compatible.