PVP proposal: no upper bounds on non-upgradeable packages

[Adam Bergmark]

I agree with Erik that non-upgradeable packages should be constrained to
installed in Cabal. I have this in my cabal config as well. Better error
messages for this would be gravy.

> Upper bounds should not be included on non-upgradeable packages, such as
base and template-haskell (are there others?).
Removing these upper bounds throws away what I consider vital information:
What version of GHC was this package successfully built against? As was
discussed elsewhere, perhaps base and other core packages should have fewer
breaking changes instead.

> Alternatively, we should establish some accepted upper bound on these
packages, e.g. many people place base < 5 on their code.
I would be okay with this if we knew what would change up until base 5, but
we don't so I think the effect would be the same as if the upper bound was
dropped.

> * Some build plans that would have previously been impossible are now
possible, without resorting to the nuclear option of --allow-newers.

I've seen this argument about making more builds plans possible several
times and I don't get it. Yes it's great if a package still works when one
of its dependencies goes through a breaking change, but the point is that
the maintainer (generally) does not know this until that version is
released. An upper bound gives the maintainer some time to test the new
version, if it's just a matter of bumping the upper bound then this can be
done really fast, if bigger changes need to be done then the lack of an
upper bound wouldn't have helped since the package was broken with that
version anyway. If we restrict this to the non-upgradeable packages,
maintainers have time to test on a new version of GHC before the next
haskell-platform release, as is the case right now.

You can probably tell that I'm -1 on this :)





On Thu, Apr 10, 2014 at 12:57 AM, Ganesh Sittampalam <ganesh at earth.li>wrote:

> -1 (because of the listed downsides)
>
> On 09/04/2014 20:24, Michael Snoyman wrote:
> > At Herbert's request, I'm splitting off this part of the PVP proposal I
> > made[1] to its own separate proposal. Same discussion period of three
> > weeks. The proposal is:
> >
> > Upper bounds should not be included on non-upgradeable packages, such as
> > base and template-haskell (are there others?). Alternatively, we should
> > establish some accepted upper bound on these packages, e.g. many people
> > place base < 5 on their code.
> >
> > The purpose (elaborated in my blog post[2]) is that these upper bounds
> > virtually never provide for a successful build. Instead, they are purely
> > about what error messages the user receives. With this change:
> >
> > * Some build plans that would have previously been impossible are now
> > possible, without resorting to the nuclear option of --allow-newers.
> > * Instead of cabal version bound error messages, users get GHC compiler
> > errors that can be fed back upstream to help get packages fixed more
> > expediently.
> >
> > Downsides I'm aware of:
> >
> > * If you consider the cabal error messages more user friendly, then the
> > error message quality goes down.
> > * Users may find out later than they do right now about a failing build.
> >
> > [1] http://www.haskell.org/pipermail/libraries/2014-April/022529.html
> > [2] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140410/b6196857/attachment.html>