Gershom B
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#Propo...