[GHC DevOps Group] Making GHC's fast release cadence work
Ben Gamari
ben at smart-cactus.org
Tue Jul 2 16:46:08 UTC 2019
Simon Peyton Jones via Libraries <libraries at haskell.org> writes:
> | - the kicker: Any library that wishes to be included in GHC / base *must
> | share maintainership* with the GHC release team / libraries committee,
> | respectively/./ That means those groups can release things whenever they
> | want to unblock themselves.
>
> That seems very plausible to me. But "sharing maintainership" could be limited to:
>
> The GHC release team is free to make a minor (patch-level)
> release of an existing released version of the library L,
> embodying any changes necessary to make the library work
> with the new version of GHC
>
> I think that is all that's needed. In general GHC should not rely
> on a bleeding-edge release of a library. But it's not uncommon
> for tiny changes to be needed, and by sharing maintainership, the
> library author would not need to be bothered about making and
> releasing those changes.
>
Yes, this is precisely what I was trying to articulate in my original
email (although failed to do so clearly). We would not want to be
responsible for managing major releases; merely incremental patch-level
releases to patch things up to be shippable with GHC.
Cheers,
- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20190702/e08128b1/attachment-0001.sig>
More information about the Ghc-devops-group
mailing list