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 <gersh...@gmail.com>: > > 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
