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