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

[MigMit]

What if instead of upper (and lower) bounds we just specify our interface requirements? Like "package bull-shit should provide value Foo.Bar.baz :: forall a. [a] -> [a] -> [a] or more general". Sure, it won't help dealing with strictness/lazyness, but it would capture most interface differences. And, in case the requirements aren't specified, we could also specify the default, like "bool-shit 2.0 is known to fulfil this requirement; if yours doesn't, consider installing this one".


On Aug 17, 2012, at 7:28 PM, Leon Smith <leon.p.smith at gmail.com> wrote:

> 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. _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe