[GHC DevOps Group] Making GHC's fast release cadence work

[Moritz Angermann]

> Moritz has been pushing this effort further via https://gitlab.haskell.org/ghc/ghc/merge_requests/490 but it didn't make it into GHC 8.8 yet.

@John Ericson has been working on making ghc multi-target, which makes
this much easier. So I'll rebase once that work is done.
BUT: a big issue I've run into with a reinstallable lib:ghc is that it
essentially breaks anything that somehow tied to ghc: Plugins,
doctest, ... as you end up with two instances of `ghc` (one in ghc
(stock lib:ghc), the other one (reinstalled lib:ghc) in the library
you
are linking). Now I had naively hoped this could *just* work out, but
it didn't.

On Tue, Jul 9, 2019 at 4:29 PM Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
>
> > The biggest problems are for packages like containers, that are not only used by GHC but also exposed to users through the GHC API. These libraries aren't part of GHC or base, but pretty much have to move in lock step.
>
> fwiw, this what
> https://mail.haskell.org/pipermail/ghc-devs/2017-July/014424.html aims
> to address and would help to reduce this artificial boot-library
> version pinning for consumers. Moritz has been pushing this effort
> further via https://gitlab.haskell.org/ghc/ghc/merge_requests/490 but
> it didn't make it into GHC 8.8 yet.