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

[Leon Smith]

I see good arguments on both sides of the upper bounds debate,  though at
the current time I think the best solution is to omit upper bounds (and I
have done so for most/all of my packages on hackage).    But I cannot agree
with this enough:

On Thu, Aug 16, 2012 at 4:45 AM, Joachim Breitner
<mail at joachim-breitner.de>wrote:

> I think what we’d need is a more relaxed policy with modifying a
> package’s meta data on hackage. What if hackage would allow uploading a
> new package with the same version number, as long as it is identical up
> to an extended version range? Then the first person who stumbles over an
> upper bound that turned out to be too tight can just fix it and upload
> the fixed package directly, without waiting for the author to react.
>

I think that constraint ranges of a given package should be able to both be
extended and restricted after the fact.   Those in favor of the reactionary
approach (as I am at the moment, or Bryan O'Sullivan) would find the
ability of to restrict the version range useful,  while those in favor of
the proactive approach (like Joachim Breitner or Doug Beardsley) would find
the ability to extend the version range useful.

I suspect that attitudes towards upper bounds may well change if we can set
version ranges after the fact.    I know mine very well might.    And the
difference between reactionary and proactive approaches I think is a
potential justification for the "hard" and "soft" upper bounds;  perhaps we
should instead call them "reactionary" and "proactive" upper bounds instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120817/0e95568d/attachment.htm>