Release/git plans

austin seipp as at
Thu Jan 20 17:57:02 CET 2011

Hello Simon,

On Thu, Jan 20, 2011 at 9:48 AM, Simon Marlow <marlowsd at> wrote:
> ...
>  - make a new stable branch for 7.2, and release 7.2.1 shortly after.
> So we'll be doing a 7.2.1 release much earlier than planned.  Our motivation
> for doing this is:
>  - the 7.0 branch is darcs, but the HEAD will be git, so the longer
>   this situation persists the more difficult it is to merge changes.
>   Hence we want to fork a new STABLE branch as soon as possible.
>  - one of the fixes we need to make soon, to fix equality superclasses,
>   is too large a change to put in the 7.0 branch.  We also have some
>   pending changes to the internal representation of coercions that
>   will be disruptive in HEAD, and will make future merging to 7.0
>   difficult.
>  - 7.0.2 should be a nice stable release, and HEAD is actually in
>   pretty good shape right now too.

So, given that 7.2 will be released much earlier than the normal
release cycle, is there any room for anything else to get into HEAD
for the 7.2 release before everything is switched? In particular I
fixed up Max Bolingbroke's old compiler plugin work to be usable with
the latest HEAD, and all the fundamental work is there and done, just
some additional small things are needed (notably having ghc dump
plugin information a la -ddump flags, and testsuite patches are about
it I think.) The patch itself is pretty small and doesn't touch *too*
much code, mostly adding dynamic loading and the plugin API, but it's
arguably adding a 'big' feature for users of GHC to start utilizing,
and perhaps a release in 7.2 would cause problems merging changes
until you cut a new STABLE branch with git, like you said.

It would be nice to have this in GHC 7.2, but I was thinking of
eventually extending the scope of compiler plugins to allow users to
write Cmm optimisations as well. It would likely be best to wait for
the switch to Git and for the new code generator branch to be merged
before that work happens though, but writing plugins that do Core
passes seem to work well right now.

> The GHC git repo that
> we'll be using is here:

This is an incredibly minor note in my opinion (that was brought up
before IIRC) but, isn't it a little strange for ghc's git repository
to exist on Not that it's a problem, just slightly
confusing I guess.


More information about the Glasgow-haskell-users mailing list