Re: [GHC DevOps Group] Release policies

Hi Herbert, On 18 December 2017 at 12:22, Herbert Valerio Riedel wrote:

Hi Mathieu,

On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu wrote:

...

it's worth thinking about asking that the versions of all upstream packages only make it into GHC, at the behest of their respective maintainers, after a new release of upstream is made.

Let me try to formulate the invariant such a procedure would demand:

That would require a guarantee that the APIs provided by GHC (mostly ghc-prim/base, but possibly more, including other boot libs; as well as GHC's own behaviour) my package(s) rely upon are frozen to the point that any such release of my packages advertising compatiblity with the imminent GHC release will remain compatible with said final GHC release.

Is this something you're ready to guarantee?

That's exactly it: a tradeoff. As you note, any package release now can't possibly anticipate all changes in future GHC. Furthermore, if a new GHC feature crucially depends on upstream but no upstream release is available yet, under this proposal merging the new GHC feature would need to be delayed. But on the other hand, if indeed GHC is to have more frequent releases, we can't have a GHC release perennially held up by upstream maintainers cutting their own releases one after the other, or worse still, releases happening *after* it already shipped in GHC as we just saw, or with breaking changes not announced to downstream tooling authors ahead of time. This is a problem that was brought up by Ben at ICFP, and again here. It's a problem relevant to the discussion at hand, which started as the result of upstream releases showing up on Hackage long after the release, and downstream tooling authors not afforded any advance notice to adapt. When this was brought up at ICFP, several GHC DevOps Group members recommended to Ben that he avoid needing *any* cooperation from upstream maintainers on the critical path towards a release. Of the packages you mention, base can't introduce breaking changes without a grace period. Are any upstream packages that closely tied to ghc-prim etc that a breaking change in the latter is likely between feature freeze and the release date? On the off-chance that a BC change does happen, package releases are cheap, so would that really be a problem? If a package is that closely tied to ghc-prim, base or any other boot lib, and conversely GHC is closely tied to it, then shouldn't that package just be part of the GHC codebase proper, rather than managed separately outside of GHC devs' control?