On Fri, Aug 8, 2014 at 5:13 PM, Mateusz Kowalczyk
On Fri, Aug 8, 2014 at 10:11 AM, Simon Peyton Jones < simonpj@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
On 08/08/2014 10:15 AM, Johan Tibell wrote: 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.
Be careful hear so 1) patches aren't lost (that almost happened once when GHC HQ made a containers release) and 2) that the version numbers used by GHC HQ and your releases make sense (i.e. follow the PVP). P.S. I would recommend naming the main development branch 'master' and the other 'ghc-head'. 'master' is the branch new potential developers will see first on GitHub and it's the one people default to when making pull requests. I used to have the main 'network' development in a branch called 'develop'. This led to lots of confusion and pull requests against the wrong branches. The name 'ghc-head' also makes it much clearer what that branch is for and why it might be special.