more releases

[Richard Eisenberg]

On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:

> 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

This was the sort of thing I thought could be automated. I'm picturing a system where Austin/Ben hits a button and everything whirs to life, creating, testing, and posting bindists, with no people involved.

> - Writing releases notes & announcment

Release notes should, theoretically, be updated with the patches. Announcement can be automated.

> - Coordinating with the HP release process (which requires separate QA)

I'm sure others will have opinions here, but I guess I was thinking that the HP wouldn't be involved. These tiny releases could even be called something like "7.10.2 build 18". The HP would get updated only when we go to 7.10.3. Maybe we even have a binary compatibility requirement between tiny releases -- no interface file changes! Then a user's package library doesn't have to be recompiled when updating. In theory, other than the bugfixes, two people with different "builds" of GHC should have the same experience.

> - 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

Any library version change would require a more proper release. Do these libraries tend to change during a major release cycle?

> - Uploading and signing packagees to download.haskell.org, and verifying
>   the downloads 

This isn't automated?

> 
> Austin & Ben probably have more to add to this list
> 

I'm sure they do.

Again, I'd be fine if the answer from the community is "it's just not what we need". But I wanted to see if there were technical/practical/social reasons why this was or wasn't a good idea. If we do think it's a good idea absent those reasons, then we can work on addressing those concerns.

Richard

> 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