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