GHC release timing and future build infrastructure

[Ben Gamari]

Bardur Arantsson <spam at scientician.net> writes:

> On 2017-08-02 21:26, Bardur Arantsson wrote:
>
>> I'd like to add a few thoughs (or just to underscore the ones you've
>> already brought forth, as the case may be):
>> 
> [--snip--]
>> reasons -- I wouldn't presume to know. Also note that this is
>> *basically* how Rust also works, it's just that they keep the "unstable"
>> bits behind a feature flag (until they're deemed 'stable') instead of
>> actually having different code bases.
>> 
>
> Sorry about the self-reply and excesive bolding-for-emphasis. The point
> of this past paragraph was that *perhaps* GHC could move towards
> (short-lived!) "feature flags" for the compiler[1]. Again, I have no
> experience with the GHC development process so maybe it's completely
> absurd to even contemplate such a thing (in terms of effort).
>
It's not clear to me that this would work. Afterall, not all commits are
new features and, perhaps more importantly, not all bugs stem from new
features.

Rather, many of GHCs commits are in fact refactorings. This is one of
the major reasons why the codebase hasn't collapsed under its own weight
despite the last two decades of development. Sometimes these
refactorings are merely cleanups, sometimes they fix bugs, but sometimes
they also introduce bugs.

In principle, the role of a stable branch is to serve as a "known good"
state which we can place fixes that we are quite certain fix a bug
without knowingly introducing others. Of course, in part due to our long
release schedule, we have in practice been a bit more liberal in
backporting. That being said, I do fear that including all new commits, even
those that don't fix bugs, in all new releases may have the effect of
destabilizing those releases.

Of course, feel free to clarify if I've misunderstood the proposal
(which I fear I may have).

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170802/24ace989/attachment.sig>