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 <m...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
