Bardur Arantsson
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