On Wed, Feb 26, 2014 at 9:45 PM, Yitzchak Gale <gale@sefer.org> wrote:
Michael Snoyman wrote:
> 1. Make sure that any code that anyone ever wrote will continue to build in
> the future.
> 2. Provide guidelines to package authors to make sure that `cabal install
> foo` works reliably, regardless of what's happened on the rest of Hackage.
>
> It's (1) that I take huge issue with, because (as I've been trying to
> demonstrate) I don't see any way that a policy like PVP could ever fully
> solve this problem.

As a commercial shop that must reproduce builds,
we have wasted many many hours in the past on
cabal hell. Almost all of it was caused by authors
of packages we depend on omitting upper bounds.

I am aware that some people have other needs,
and have wasted their cabal hell time on the opposite
problem.

However, now the amount of time we waste on cabal
hell, though non-zero, is much less. The reason is better
ways in cabal to tweak cabal's build plan manually and
reproduce winning build plans in the future, such as
local cabal.config files. Whatever time we still do waste
is still caused by people not being careless about
upper bounds. And I believe that people with the
opposite problem are wasting less and less time
on cabal hell, too.

As better tools continually become available, it
becomes less disastrous when dependency
version bounds are not exactly right. But on the
other hand, those bounds are critically important
semantic information about a package that make
a huge contribution to the potential quality that
build tools can achieve. And only the package author
can easily provide that information

So in my opinion, the proven, working, way forward is:

1. Continue to improve cabal's build plan tools, such
as cabal freeze. And yes, cabal-timemachine would
be cool :)

2. Continue to adhere to PVP. Package authors should
do the best they can to guess the range of dependency
versions that their package is very likely to build with.

So for example:

For libraries like the tagged library, or the deepseq library,
which haven't changed in any essential way over any number
of major version bumps, go ahead and omit the upper
bound.


Actually, that's not going to help anyone much. If the library really is completely stable, then who cares if I have to change an upper bound when the package never changes?

The real issue is packages with a largely stable subset, and some other part that's still changing. The two prime examples of this are text and bytestring. Both of them expose an incredibly stable core API, which is what most people use. Occasionally, there is a new feature added, or some more obscure feature changes somehow. But likely 95% of packages depending on these two will never be affected by those changes.

Requiring every usage of text to have an upper bound stratifies Hackage into (1) packages that depend on the new features, and (2) PVP-adhering packages whose authors haven't updated their dependencies yet.

With my Stackage hat on, this is by far the most time-consuming issue I have to deal with. base squarely falls in this category, since the vast majority of it doesn't change between releases. It happens to *also* fall in the category of non-upgradeable packages.
 
For most vanilla packages, try to be as accurate as you
can about the lower bound (without going crazy), and
use a two-component upper bound.

For base, if you are not using fancy new GHC features,
minor version bumps are unlikely to break your package,
but a major bump of base (if that will ever happen again)
is likely to break quite a few packages and maybe yours.


To be clear, base has a major version bump every release of GHC. According to the PVP, the first two components of the version number constitute the major version, while the third number is the minor version.
 
For maintainers like Edward with a huge burden - well,
I'm sure Edward will figure out the most reasonable
and helpful thing to do in his situation. Perhaps higher
powered tools, like some variation on cabal-bounds,
would be helpful for him.

Etc.

Thanks,
Yitz