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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
