On Fri, Aug 8, 2014 at 5:13 PM, Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> wrote:
> 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. > 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.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs