[GHC DevOps Group] Release policies

Gershom B gershomb at gmail.com
Mon Dec 18 19:41:57 UTC 2017

Let me try to formulate a synthetic policy as per Simon's request:

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

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.


More information about the ghc-devs mailing list