release timing

[Simon Peyton Jones]

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:mark.lentczner at gmail.com]
Sent: 06 May 2015 04:47
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
Subject: Re: release timing


On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150506/2b799c1d/attachment.html>