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
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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/