[GHC DevOps Group] Release policies

[Manuel M T Chakravarty]

Simon,

As Mathieu indicated, a core problem that led to #14558 is that integer-gmp was uploaded long after the release of GHC. One simple ground rule that we should have in the release policies is that GHC never gets released until all its dependencies have been released (this means uploaded and all). If this delays a GHC release, so be it.

With respect to Cabal, one general issue (as highlighted in the discussion between Mathieu and Gershom) is the co-development of the two. This immediately leads to a policy problem: the Cabal devs are free to structure their development as they see fit and they don’t need to follow any policies that we put into place.

Hence my question: can we simply ship GHC with the latest *stable* Cabal release at the time of GHC feature freeze?

I think, this would make the process much less fragile. Also, given GHC’s intended faster release schedule, it shouldn’t slow Cabal development significantly down either.

Manuel

> 14.12.2017 03:43 Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org>:
> 
> Dear GHC devops group
> 
> The conversation on Trac #14558 <https://ghc.haskell.org/trac/ghc/ticket/14558> suggests that we might want to consider reviewing GHC’s release policies <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases>.  This email is to invite your input.
> 
> The broad questions is this. We want GHC to serve the needs of all its users, including downstream tooling that uses GHC.  What release policies will best support that goal?  For example,  we already ensure that GHC 8.4 can be compiled with 8.2 and 8.0.  This imposes a slight tax on GHC development, but it means that users don't need to upgrade quite as often.   (If the tempo of releases increases, we might want to increase the window.)
> 
> Trac #14558 suggests that we might want to ensure the metadata on GHC’s built-in libraries is parsable with older Cabals.  One possibility would be this:
> 
> Ensure that the Cabal metadata of non-reinstallable packages (e.g. integer-gmp) shipped with GHC be parsable by the Cabal versions shipped with the last two major GHC releases [i.e. have a sufficiently old cabal-version field].  That is, in general a new Cabal specification will need to be shipped with two GHC releases before GHC will use start using its features in non-reinstallable packages.
> Upholding this policy won't always be possible. There may be cases (as is the case Hadrian for GHC 8.4) where the benefit of quickly introducing incompatible syntax outweighs the need for compatibility. In this (hopefully rare) case we would explicitly advertise the incompatibility in the release documentation, and give as much notice as possible to users to allow downstream tools to adapt.
> For reinstallable packages, of which GHC is simply a client (like text or bytestring), we can’t reasonably enforce such a policy, because GHC devs have no control over what the maintainers of external core libraries put in their Cabal files.
> This is just a proposal.  The narrow questions are these:
> 
> Would this be sufficient to deal with the concerns raised in #14558?
> Is it necessary, ow would anything simpler be sufficient?
> What costs would the policy impose on GHC development?
> There may be matters of detail: e.g. is two releases the right grace period. Would one do?
> Both the broad question and the narrow ones are appropriate for the Devops group.
> 
> Thanks!
> 
> Simon
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171214/26c18687/attachment.html>