[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