[GHC DevOps Group] Release policies

[Manuel M T Chakravarty]

I believe the standard policy would be to say that even master may only dependent on released versions of dependencies. That is after all the only way to have a master that is always ready to be cut for a release (as per modern CI practices).

Given the tight coupling of some of the dependencies of GHC with GHC, maybe we need to consider something weaker, but I think, the weakest reasonable (from a CI standpoint) policy is to say that, while master may depend on pre-release versions, release branches can *only* depend on released dependencies. In other words, a release branch can only be cut when master has progressed to a point where it only depends on released versions of its dependencies.

Under that compromise, cutting a GHC release branch may be delayed by a delayed upstream release, but hopefully the approx 3 month release process has enough slack to tolerate that. (It is obviously not ideal, though.)

Cheers,
Manuel

PS: Simon, I am sorry, but IMHO it is too early for a summary and policy proposal as the discussion hasn’t really converged yet. In any case, I am happy to write a summary Trac page once we are there. Is that ok?

> 19.12.2017 06:41 Gershom B <gershomb at gmail.com>:
> 
> Let me try to formulate a synthetic policy as per Simon's request:
> 
> Policy:
> Bundled library maintainers agree to the following:
>  1) When GHC cuts a feature-freeze branch, they too (if anything has
> changed) cut a feature-freeze branch within two weeks at the maximum
> (ideally sooner), to be included in the main GHC freeze branch. If
> they do not do so, the last released version will be included instead.
>  2) When GHC releases the first release candidate, maintainers (if
> anything has changed) release new versions of their packages, to then
> be depended on directly in the GHC repo. All submodules are then
> replaced with their proper released versions for GHC release.
> 
> This policy can be enforced by GHC hq as part of the release process
> with the exception of a case in which there's coupling so that a new
> GHC _requires_ a new submodule release, and also the maintainer is not
> responsive. We'll have to deal with that case directly, likely by just
> appealing to the libraries committee or something to force a new
> release :-)
> 
> Motivation:
> This should help address multiple issues: 1) holdup of ghc on other
> releases. 2) lack of synchronization with ghc and other releases. 3)
> low lead-time for people to adapt to API changes in forthcoming
> library releases tied to ghc releases. In particular, because Cabal is
> part of this policy, it should help circumvent the sorts of problems
> that led to this thread initially. Further, because this only applies
> to freeze/release branches, it should not slow down
> rapid-implementation of cross-cutting changes more generally.
> 
> Cheers,
> Gershom
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs