more releases

[Herbert Valerio Riedel]

On 2015-09-01 at 08:45:40 +0200, Richard Eisenberg wrote:
> An interesting topic came up over dinner tonight: what if GHC made
> more releases? As an extreme example, we could release a new point
> version every time a bug fix gets merged to the stable branch. This
> may be a terrible idea. But what's stopping us from doing so?
>
> The biggest objection I can see is that we would want to make sure
> that users' code would work with the new version. Could the Stackage
> crew help us with this? If they run their nightly build with a release
> candidate and diff against the prior results, we would get a pretty
> accurate sense of whether the bugfix is good. If this test succeeds,
> why not release? Would it be hard to automate the packaging/posting
> process?
>
> The advantage to more releases is that it gets bugfixes in more hands
> sooner. What are the disadvantages?

I'd say mostly organisational overhead which can't be fully automated
(afaik, Ben has already automated large parts but not everything can be):

 - Coordinating with people creating and testing the bindists
 - Writing releases notes & announcment
 - Coordinating with the HP release process (which requires separate QA)
 - If bundled core-libraries are affected, coordination overhead with package
   maintainers (unless GHC HQ owned), verifying version bumps (API diff!) and
   changelogs have been updated accordingly, uploading to Hackage
 - Uploading and signing packagees to download.haskell.org, and verifying
   the downloads 

Austin & Ben probably have more to add to this list

That said, doing more stable point releases is certainly doable if the
bugs fixed are critical enough. This is mostly a trade-off between time
spent on getting GHC HEAD in shape for the next major release (whose
release-schedules suffer from time delays anyway) vs. maintaining a
stable branch.

Cheers,
  hvr