| 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?
Yes, I'm perfectly happy with that, thank you. I just wanted to be sure that the discussion eventually converged rather than petering out. Many thanks to Gershom for putting out a concrete suggestion; I think that concrete proposals can help to focus a debate. Simon | -----Original Message----- | From: Manuel M T Chakravarty [mailto:c...@justtesting.org] | Sent: 19 December 2017 10:16 | To: Gershom Bazerman <gersh...@gmail.com>; Simon Peyton Jones | <simo...@microsoft.com> | Cc: ghc-devs <ghc-devs@haskell.org>; ghc-devops-gr...@haskell.org | Subject: 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 <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