[GHC DevOps Group] Release policies

[Ben Gamari]

Gershom B <gershomb at gmail.com> writes:

> This proposal seems to have trailed off. I think it is worth putting a bow
> on it and getting it signed off on for the GHC release policy page.
>
Yes, thanks for reviving this. I agree; we should wrap this up.


> Let me restate it:
>
>
> Bundled library maintainers agree to the following responsibilities:
>
> 1) When GHC cuts a feature-freeze branch, they too (if anything has
> changed) cut a feature-freeze branch within two weeks at the maximum
> (ideally sooner), to be included in the main GHC freeze branch. If
> they do not do so, the last released version will be included instead.
>
This last sentence is a bit of an empty threat, I'm afraid. In most
cases we sadly have little choice but to update all core libraries since
they at very least need a bounds bump. In the case that *only* a bounds
bump is needed I suppose we could push a Hackage revision.

> 2) When GHC releases the first release candidate, maintainers (if
> anything has changed) release new versions of their packages, to then
> be depended on directly in the GHC repo. All submodules are then
> replaced with their proper released versions for GHC release.
>
Yes, this sounds right to me. The only trouble that I can foresee is the
difficulty of propagating the bounds down the core library dependency
tree: Major bumps in packages like filepath tend to be rather painful as
they require bumps in dependent libraries like directory, which in turn
requires bumps in Cabal, etc.

I suppose all we can really do is hope that upstreams are responsive
enough to ensure that this whole process fits in the two-week window.
This hasn't always been the case in the past, but perhaps having formal
policies in place will help.

If there is no objection from the devops group, I can send a message to
the core library upstream maintainers describing the proposed policy.
I've put up a brief description of the policy on the Wiki [1].

>
> I know Chak and I had a back and forth, but I consider it resolved in the
> direction of this proposal at this point, as a strict improvement over the
> current situation that does not seem to invite further controversy. If in
> the event of future things we learn, this proposal is inadequate, we can
> revisit then.
>
> The one thing missing from both this proposal and the current release
> policy page in general is discussion of the head overlay to hackage. I
> think discussion of this should be integrated in both as a separate issue.
> In particular — the feature freeze branches of bundled libraries can and
> should be regularly updated in the head overlay.
>
Yes, I think the head.hackage issue is rather orthogonal to the matter
of core library releases. It would make sense to mention it onn the
releases page, but I personally don't feel as though I've had enough
experience to distill a convenient work-flow using head.hackage, so I
suspect there is more work to be done before this can be done.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BootLibraries#Proposedreleasepolicy
-------------- 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-devs/attachments/20180219/2a7e8208/attachment.sig>