Gershom B <gersh...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
