Fwd: Release policies

Michael Snoyman michael at snoyman.com
Fri Dec 15 09:27:06 UTC 2017

On Fri, Dec 15, 2017 at 12:10 PM, Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> |  at this point in time Stackage works
> |  hard to ensure that in any given package set, there is *exactly one*
> |  version of any package. That's why Stackage aligns versions of core
> |  packages to whatever ships with the GHC version the package set is
> |  based on.
> Ah. It follows that if Stackage wants to find a set of packages compatible
> with GHC-X, then it must pick precisely the version of bytestring that
> GHC-X depends on.  (I'm assuming here that GHC-X fixes a particular
> version, even though bytestring is reinstallable?  Certainly, a
> /distribution/ of GHC-X will do so.)
> If meanwhile the bytestring author has decided to use a newer version of
> .cabal file syntax, then GHC-X is stuck with that.  Or would have to go
> back to an earlier version of bytestring, for which there might be material
> disadvantages.
> That would make it hard to GHC to guarantee to downstream tools that it
> doesn't depend on any packages whose .cabal files use new syntax; which is
> where this thread started.
> Hmm.  I wonder if I have understood this correctly.  Perhaps Michael would
> like to comment?
Stackage does in fact pin snapshots down to precisely one version of each
package. And in the case of non-reinstallable packages, it ensures that
those package's transitive dependency set are pinned to the same version
that ships with GHC. I know there's work around making more package
reinstallable, and the ghc package itself may have crossed that line now,
but for the moment Stackage assumes that the ghc package and all its
dependencies are non-reinstallable. Therefore bytestring, process,
containers, transformers, and many more will be pinned in a Stackage

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171215/2d13f353/attachment.html>

More information about the ghc-devs mailing list