On 08/08/2014 10:15 AM, Johan Tibell wrote: > On Fri, Aug 8, 2014 at 10:11 AM, Simon Peyton Jones <simo...@microsoft.com> > wrote: > >> The biggest disadvantage in my mind is that you're setting yourself up >> for a potentially huge merge just before the GHC release and might block >> the GHC release until that merge is done (assuming that haddock is still >> shipped with GHC). >> >> >> >> Excellent point. >> >> >> >> The merge shouldn’t block the release, though. In extremis, I guess we >> could always release the GHC fork of Haddock if the tip of Haddock wasn’t >> merged to match GHC! But I doubt it’ll come to that >> > > But as you mentioned the GHC fork of Haddock might not work (it might just > type check) so at the very least Mateusz is signing up for validating that > it indeed works before a GHC release. That's of course fine, I just want > people to understand what we're signing up for. >
Well, I stick around and am usually aware of GHC release early. In the usual case Haddock will be fixed up before the actual GHC release. I don't think API changes were ever drastic enough to provide major problems especially seeing as I'll be able to refer to the GHC-tracked branch to see what patches were applied there. However let's consider I can't make it for the release because I'm not available around that time or otherwise. This should still not hold up GHC release. I would expect the GHC team to release Haddock + their fixes, it would simply be like an existing release with some patches on top to have it work with new GHC. I can then come around and once I apply any API patches, I make an actual Haddock release. People can then simply cabal install haddock and use what they get here rather than what came with GHC. Does this make sense? -- Mateusz K. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs