release timing

[Alan & Kim Zimmerman]

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 <simonpj at microsoft.com>
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: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>
> 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
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150506/00133322/attachment-0001.html>