Tentative high-level plans for 7.10.1
johan.tibell at gmail.com
Mon Oct 6 09:38:31 UTC 2014
On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at utwente.nl wrote:
> > The danger, of course, is that people aren't very enthusiastic about
> > bug-fixing older versions of a compiler, but for
> > language/compiler-uptake, this might actually be a Better Way.
> Maybe some of the commercial GHC users might be interested in donating
> the manpower to maintain older GHC versions. It's mostly a
> time-consuming QA & auditing process to maintain old GHCs.
What can we do to make that process cheaper? In particular, which are the
manual steps in making a new GHC release today?
In the long run back porting bugfixes is the route successful OSS projects
take. Once people have written large enough Haskell programs they will stop
jumping onto the newer version all the time and will demand backports of
bug fixes. This is already happening to some extent in cabal (as cabal is
tied to a ghc release which means we need to backport changes sometimes.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs