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