<div dir="ltr"><div><div>But equally, stackage is a major part of the haskell ecosystem.<br><br></div>As such, implications and paths forward need to be considered.<br><br></div>Alan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 June 2017 at 11:16, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Simon,<br>
<br>
On 2017-06-09 at 09:50:51 +0200, Simon Peyton Jones via ghc-devs wrote:<br>
<br>
[...]<br>
<span class=""><br>
>> Stackage only allows one version of each package<br>
><br>
> I didn’t know that, but I can see it makes sense.  That makes a strong<br>
> case for re-doing it as a new package hoopl2<br>
<br>
</span>The limitations of Stackage's design shouldn't drive nor limit<br>
library design. Cabal has been moving to finally allow us to have<br>
multiple versions and even multiple configurations/instances of the same<br>
version of a package registered in the package db at the same time, and<br>
subjecting ourselves to Stackage's limitations after all the work done<br>
(and more in that direction is being considered to push the boundaries<br>
even further) to that effect *now* seems quite backward to me.<br>
<br>
If we push the idea to its conclusion, that we shall rather publish a<br>
new package rather than release a new major version of a package to<br>
workaround Stackage, you'd see a proliferation of number-suffixed<br>
packages on Hackage.  Moreover, packages which can easily support<br>
multiple major versions of a package would have to use conditional logic<br>
boilerplate in their .cabal files (which again would be incompatible<br>
with Stackage's inherent limitations, as it allows only *one<br>
configuration* of a given package version).<br>
<br>
We should build upon the facilities we already have in place; and major<br>
versions are here to encode the epoch/generation of an API; moreover, as<br>
a big advantage over classic SemVer, we also have this 2-component major<br>
version which gives us more flexibility for versioning during developing<br>
two or more epochs of an API in parallel. So hoopl-1.* and hoopl-2.*<br>
could keep evolving independently, each branch being able to perform<br>
major version increments in their respective version namespace.<br>
<br>
Cheers,<br>
  HVR<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>