[GHC DevOps Group] Release policies

[Boespflug, Mathieu]

Hi Herbert,

On 18 December 2017 at 12:22, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> Hi Mathieu,
>
> On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu <m at tweag.io> 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?