Tentative high-level plans for 7.10.1

[Austin Seipp]

First off, I just wanted to tell everyone - thank you for the feedback!

I actually left these tickets in their place/milestones just in case
something like this popped up, so I wouldn't have to undo it later. It
seems like there's actually a fair amount of support for 7.8.4, where
before we didn't get much of an indication as to user needs.

As a result, I'll be leaving the 7.8.4 milestone tickets, but will
still cull them down to what's acceptable, and we'll aim for those.
#8960 seems to be the main one.

As I said in the initial email, I'll follow up on this shortly after
this, later today.

On Tue, Oct 7, 2014 at 6:46 AM, Mikolaj Konarski <mikolaj at well-typed.com> wrote:
>> Our intent has always been that that the latest version on each branch is solid.  There have been one or two occasions when we have knowingly abandoned a dodgy release branch entirely, but not many.
>
> Perhaps we could do the opposite. Announce beforehand that
> a release branch X is going to be LTS (of Very Stable Release;
> roughly 1 in 4 branches?) and so very few major new features
> will be included in the release X+1 (there is just not enough
> time for both, as Austin explained).
> Then, on the GHC maintainers' side, put off accepting any
> "I rewrote the compiler" commits into HEAD for long time.
> On the community side, focus on bug fixes and non-disruptive,
> incremental improvements. Avoid API changes, whatever that means.
> Update release X many times, until very stable.
>
> A more radical proposal would be to do the above, but announce
> that X+! is going to be Very Stable Release and accept no major
> new features into HEAD at all and even revert any minor new
> features just before X+1 release, if non-trivial bugs in them are discovered.
> Then release X can be abandoned quickly, knowing that X+! will most
> probably resolve any problems in X, without introducing new ones.
>
> In either case, the main point is the announcement and so the
> focus of the community on bug-fixing and keeping HEAD close
> to the named releases, to make bug-fixing and back- and forward-
> porting easy.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/