[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[Yitzchak Gale]

Bryan O'Sullivan wrote:
> A substantial number of the difficulties I am encountering are related to
> packages specifying upper bounds on their dependencies. This is a recurrent
> problem, and its source lies in the recommendations of the PVP itself

I think the PVP recommendation is good, though admittedly
one that in practice can be taken with a grain of salt.

Publishing supposedly stable and supported packages
with no upper bounds leads to persistent build problems
that are tricky to solve.

A good recent example is the encoding package.
This package depends on HaXML >= 1.19, with
no upper bound. However, the current version of HaXML
is 1.23, and the encoding package cannot build
against it due to API changes. Furthermore, uploading
a corrected version of encoding wouldn't even
solve the problem completely. Anyone who already
has the current version of encoding will have
build problems as soon as they upgrade HaXML.
The cabal dependencies are lying, so there is no
way for cabal to know that encoding is the culprit.
Build problems caused by missing upper bounds
last forever; their importance fades only gradually.

Whereas it is trivially easy to correct an upper
bound that has become obsolete, and once you
fix it, it's fixed.

For actively maintained packages, I think the
problem is that package maintainers don't find
out promptly that an upper bound needs to be
bumped. One way to solve that would be a
simple bot that notifies the package maintainer
as soon as an upper bound becomes out-of-date.

For unresponsive package maintainers or
unmaintained packages, it would be helpful to
have some easy temporary fix mechanism as
suggested by Joachim.

Joachim also pointed out the utility of upper bounds
for platform packaging.

Why throw away much of the robustness of
the package versioning system just because
of a problem we are having with these trivially
easy upper-bound bumps?  Let's just find a
solution for the problem at hand.

Thanks,
Yitz