Plan for GHC 9.2

[Sebastian Graf]

Hi Ben,

Since part of the changes of
https://gitlab.haskell.org/ghc/ghc/-/issues/14422 are already merged into
master (e.g. we ignore the "type signature" part of a COMPLETE sig now,
because there is nothing to disambiguate), it would be good if we merged
the solution outlined in
https://gitlab.haskell.org/ghc/ghc/-/issues/14422#note_321645, as that
would allow users to switch to a new, better mechanism instead of
discovering that COMPLETE signatures seemingly have been ripped of a
feature.
The problem with that is that it needs a GHC proposal, I think, and that's
not written yet.

Also I hope to merge some efforts in the CPR area before the fork. But
that's quite optional.

Cheers,
Sebastian

Am Do., 4. Feb. 2021 um 19:56 Uhr schrieb Ben Gamari <ben at well-typed.com>:

>
> tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
>        especially if you have something you would like merged for 9.2.1.
>
> Hello all,
>
> With GHC 9.0.1 at long-last out the door, it is time that we start
> turning attention to GHC 9.2. I would like to avoid making the mistake
> made in the 9.0 series in starting the fork in a state that required a
> significant amount of backporting to be releaseable. Consequently, I
> want to make sure that we have a fork schedule that is realistic given
> the things that need to be merged for 9.2. These include:
>
>  * Update haddock submodule in `master` (Ben)
>  * Bumping bytestring to 0.11 (#19091, Ben)
>  * Finishing the rework of sized integer primops (#19026, John Ericson)
>  * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry)
>  * Merge BoxedRep (#17526, Ben)
>  * ARM NCG backend and further stabilize Apple ARM support? (Moritz)
>  * Some form of coercion zapping (Ben, Simon, Richard)
>  * Tag inference analysis and tag check elision (Andreas)
>
> If you see something that you would like to see in 9.2.1 please do
> holler. Otherwise, if you see your name in this list it would be great
> if you could let me know when you think your project may be in a
> mergeable state.
>
> Ideally we would strive for a schedule like the following:
>
>     4 February 2021:   We are here
>        ~4 weeks pass
>     3 March 2021:      Release branch forked
>        1 week passes
>     10 March 2021:     Alpha 1 released
>        3 weeks pass
>     31 March 2021:     Alpha 2 released
>        2 weeks pass
>     14 April 2021:     Alpha 3 released
>        2 weeks pass
>     28 April 2021:     Alpha 4 released
>        1 week passes
>     5 May 2021:        Beta 1 released
>        1 week passes
>     12 May 2021:       Release candidate 1 released
>        2 weeks pass
>     26 May 2021:       Final release
>
> This provides ample time for stabilization while avoiding deviation from
> the usual May release timeframe. However, this would require that we
> move aggressively to start getting the tree into shape since the fork
> would be less than four weeks away. I would appreciate contributors'
> thoughts on the viability of this timeline.
>
> Cheers,
>
> - Ben
> _______________________________________________
> 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/20210204/3aa66a46/attachment.html>