Re: [GHC DevOps Group] Release policies

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 :

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