As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach! :)<div><br></div><div>plus the whole improving ecosystem of build bot tools which play nice with cabal et al that are cropping up mean that &quot;in principal&quot; we could debug missing upper bounds via sort of temporal bisecting over the &quot;event stream&quot; of maximum available versions at a given time to sort that. (but that piece isn&#39;t that important)<div>

<br></div><div>more pragmatically, cabal when used with hackage doesn&#39;t let you override version constraints, it just lets you add additional constraints. This makes sense if we assume that the library author is saying &quot;things will definitely break if you violate them&quot;, but in practice upper bounds are made up guesstimation. </div>

<div><br>YES, its presumably semantic versioning doesn&#39;t create a problem, but with the hackage eco system, when dealing with intelligently engineering libs that are regularly maintained, version upper bounds create more problems than than solve.</div>

<div><br></div><div>just my two cents. (yes yes yes, please drop upper bounds!)<br><br>cheers</div><div>-Carter<br><br><div class="gmail_quote">On Wed, Aug 15, 2012 at 5:04 PM, Michael Blume <span dir="ltr">&lt;<a href="mailto:blume.mike@gmail.com" target="_blank">blume.mike@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">&gt; it&#39;s usual for the existing upper bounds to refer to versions that don&#39;t exist at the time of writing (and hence can&#39;t be known to be stable).<br>


<br>
</div>Well, known to be stable given semantic versioning, then.<br>
<br>
<a href="http://semver.org/" target="_blank">http://semver.org/</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Aug 15, 2012 at 1:55 PM, Bryan O&#39;Sullivan &lt;<a href="mailto:bos@serpentine.com">bos@serpentine.com</a>&gt; wrote:<br>
&gt; On Wed, Aug 15, 2012 at 1:50 PM, David Thomas &lt;<a href="mailto:davidleothomas@gmail.com">davidleothomas@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Would it make sense to have a known-to-be-stable-though soft upper bound<br>
&gt;&gt; added proactively, and a known-to-break-above hard bound added reactively,<br>
&gt;&gt; so people can loosen gracefully as appropriate?<br>
&gt;<br>
&gt; I don&#39;t think so. It adds complexity, but more importantly it&#39;s usual for<br>
&gt; the existing upper bounds to refer to versions that don&#39;t exist at the time<br>
&gt; of writing (and hence can&#39;t be known to be stable).<br>
</div></div><div class="HOEnZb"><div class="h5">&gt; _______________________________________________<br>
&gt; Haskell-Cafe mailing list<br>
&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div></div>