Dear GHC devops group

The conversation on Trac #14558 suggests that we might want to consider reviewing GHC’s release policies.  This email is to invite your input.

The broad questions is this. We want GHC to serve the needs of all its users, including downstream tooling that uses GHC.  What release policies will best support that goal?  For example,  we already ensure that GHC 8.4 can be compiled with 8.2 and 8.0.  This imposes a slight tax on GHC development, but it means that users don't need to upgrade quite as often.   (If the tempo of releases increases, we might want to increase the window.)

Trac #14558 suggests that we might want to ensure the metadata on GHC’s built-in libraries is parsable with older Cabals.  One possibility would be this:

• Ensure that the Cabal metadata of non-reinstallable packages (e.g. integer-gmp) shipped with GHC be parsable by the Cabal versions shipped with the last two major GHC releases [i.e. have a sufficiently old cabal-version field].  That is, in general a new Cabal specification will need to be shipped with two GHC releases before GHC will use start using its features in non-reinstallable packages.
• Upholding this policy won't always be possible. There may be cases (as is the case Hadrian for GHC 8.4) where the benefit of quickly introducing incompatible syntax outweighs the need for compatibility. In this (hopefully rare) case we would explicitly advertise the incompatibility in the release documentation, and give as much notice as possible to users to allow downstream tools to adapt.
• For reinstallable packages, of which GHC is simply a client (like text or bytestring), we can’t reasonably enforce such a policy, because GHC devs have no control over what the maintainers of external core libraries put in their Cabal files.

This is just a proposal.  The narrow questions are these:

• Would this be sufficient to deal with the concerns raised in #14558?
• Is it necessary, ow would anything simpler be sufficient?
• What costs would the policy impose on GHC development?
• There may be matters of detail: e.g. is two releases the right grace period. Would one do?

Both the broad question and the narrow ones are appropriate for the Devops group.

Thanks!

Simon