more releases

[Simon Peyton Jones]

Merging and releasing a fix to the stable branch always carries a cost: it might break something else.  There is a real cost to merging, which is why we've followed the lazy strategy that Ben describes.

Still, even given the lazy strategy we could perfectly well put out minor releases more proactively; e.g. fix one bug (or a little batch) and release.  Provided we could reduce the per-release costs.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben
|  Gamari
|  Sent: 02 September 2015 17:05
|  To: Richard Eisenberg
|  Cc: GHC developers
|  Subject: Re: more releases
|  
|  Richard Eisenberg <eir at cis.upenn.edu> writes:
|  
|  > I think some of my idea was misunderstood here: my goal was to have
|  > quick releases only from the stable branch. The goal would not be to
|  > release the new and shiny, but instead to get bugfixes out to users
|  > quicker. The new and shiny (master) would remain as it is now. In
|  > other words: more users would be affected by this change than just
|  the
|  > vanguard.
|  >
|  I see. This is something we could certainly do.
|  
|  It would require, however, that we be more pro-active about continuing
|  to merge things to the stable branch after the release.
|  Currently the stable branch is essentially in the same state that it
|  was in for the 7.10.2 release. I've left it this way as it takes time
|  and care to cherry-pick patches to stable. Thusfar my poilcy has been
|  to perform this work lazily until it's clear that we will do another
|  stable release as otherwise the effort may well be wasted.
|  
|  So, even if the steps of building, testing, and uploading the release
|  are streamlined more frequent releases are still far from free.
|  Whether it's a worthwhile cost I don't know.
|  
|  This is a difficult question to answer without knowing more about how
|  typical users actually acquire GHC. For instance, this effort would
|  have minimal impact on users who get their compiler through their
|  distribution's package manager. On the other hand, if most users
|  download GHC bindists directly from the GHC download page, then
|  perhaps this would be effort well-spent.
|  
|  Cheers,
|  
|  - Ben