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
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