[GHC DevOps Group] Release policies
michael at snoyman.com
Tue Dec 19 15:12:37 UTC 2017
Thanks for spelling this out Gershom. Reading it through, here are my
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:
> 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.
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs