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 <gersh...@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs