[GHC DevOps Group] Release policies

[Michael Snoyman]

Thanks for spelling this out Gershom. Reading it through, here are my
questions:

1. What's the definition of "feature freeze"? Does it mean API stability?
Does it mean not code changes at all except to fix a bug? Are performance
fixes allowed in that case?
2. What's the minimum time between GHC cutting a feature-freeze branch and
the first release candidate? And the minimum time between first release
candidate and official release? Obviously, if each of these is 1 week
(which I can't imagine would be the case), then these libraries could cut a
feature-freeze branch after the official release, which obviously isn't
intended. I apologize if these timings are already well established, I'm
not familiar enough with GHC release cadence to know.

I can't speak to GHC development itself, but from a downstream perspective,
this sounds like the right direction.

On Mon, Dec 18, 2017 at 9:41 PM, Gershom B <gershomb at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171219/257f7e4e/attachment.html>