On the automated build front, there are now nightly builds for 7.10.1 on stackage [1].
Running a stackage instance with 7.10.2 could serve as a good confirmation test prior to release. Alan [1] https://www.stackage.org/nightly/2015-05-05 On Wed, May 6, 2015 at 11:58 AM, Simon Peyton Jones <[email protected]> wrote: > Mark > > > > Good points but: > > · If literally no one actually finds the absence of 7.10.2 a > problem, we could save a lot of work (for you) by not releasing it! I > think it’s reasonable to have some evidence of need before investing the > effort (for both GHC and HP) needed for a release. > > · The tremendous amount of contingent work for HP should be > orders of magnitude less for a patch-level release. Remember, there are > supposed to be *no API changes*, just bug fixes. So if it worked with > 7.10.1, it should work with 7.10.2. That’s why I said “press the button”. > Suppose you did just do the automated build with exact same libraries as > you currently have for 7.10.1. If that *doesn’t* work, that’s > interesting… it’s not supposed to happen. And it would be good to know if > it does. > > So I think there should be precisely zero work for library authors to stay > abreast of 7.10.2 > > Does that help? I’m sure I’m misunderstanding something important – > apologies if so. > > Simon > > > > *From:* Mark Lentczner [mailto:[email protected]] > *Sent:* 06 May 2015 04:47 > *To:* Simon Peyton Jones > *Cc:* [email protected] > *Subject:* Re: release timing > > > > > > On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones <[email protected]> > wrote: > > *So the current status is that we’ll hold it until someone says “getting > 7.10.2 out really matters to me”.* Other things being equal, the longer > we wait, the more fixes will be in. > > > > This seems like a pretty ad hoc way to release a mature project. While it > may be fine for GHC central to be happy living on tip-o-master until such > time as someone decides to stamp a tag on it, for anyone with anything that > is based on "official releases", this sort of "radioactive decay" model of > releasing makes any planning and work scheduling neigh impossible. > > > > But does anything stand in the way of pressing the button on the HP build, > so that you have a HP 7.10.2 ready to go? You can always press the button > again if/when further fixes go in. > > > > There is a tremendous amount of contingent work that goes into the > libraries that make up the HP. In order for us to beat the bushes and > ensure that everything is in shape to ship with the GHC release, we need > some sense of when the release is, and preferably a few weeks before hand > notice. Asking all the library authors to keep their libraries up-to-date, > with numbered releases on Hackage, with tip-o-7.10.2 GHC as it goes is > asking too much. > > > > Ideally, development would follow a schedule like this: > > - T -8 weeks - GHC Central announces the date of the next release (T) > - T -7 weeks - HP assembles library list, puts maintainers on notice > of impending release > - T -4 weeks - GHC releases alpha builds, HP team does test builds, > notifies library maintainers of needed updates > - T -3 weeks - HP releases alpha build > - T -2 weeks - GHC releases beta builds > - T -1 week - HP releases beta build > - T -2 days - GHC releases release candidate > - T -1 day - HP releases release candidate > - T - GHC & HP release at same time > > I can't imagine mobilizing the volunteer army any faster than that. I, > for one, have to plan for weekends "off from the family" so that I can put > out the final release - and these things have to be scheduled. > > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
