9.4 release planning (& GHCJS merge process)

[Matthew Pickering]

1. We will provide a migration guide. The draft for the guide is
located here - https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4

2. 8.10 has never officially been an LTS but due to various reasons
has been a larger number of backports than other releases. I suggest
that the decision about whether the 9.4 release will attain a similar
status is left to the community rather than us (the developers) who
lack perspective about
how companies are using releases unless explicitly told about it.

3. The likely highlights was a list produced by Ben after the 9.2
release was finalised. Most (if not all) the features on the list will
be present in the release. Of course, comprehensive release notes will
be produced which detail all the new features and changes.

4. It is an unfortunate fact that whatever the proposed release
schedule has been that the releases have never actually come at those
timings. Again, I think we have to defer the question about release
frequency to the wider community. The decision about this release
cycle was made after considering the state of the master branch, which
features we wanted in the release and the availability of the release
managers.

Cheers,

Matt

On Tue, Feb 22, 2022 at 7:34 PM Hécate <hecate at glitchbra.in> wrote:
>
> Hi Matthew, thank you for this update and the other one regarding your team.
>
> I have multiple questions regarding the release:
>
> 1. Could a migration guide be provided? Or better, a script/tool? From
> what I understand, going from 9.2 to 9.4 means breaking changes have
> been introduced.
>
> 2. The 8.10 series has gained a status of LTS amongst industrial users,
> thanks to both the numerous backports but also the wider support in the
> ecosystem. Could you please clarify whether or not it will still be an
> LTS after this release, and the status of 9.0 and 9.2 (which have
> brought numerous new things themselves but seem to have been quickly
> replaced by the next release each time). It's quite confusing, and when
> the question arises in professional circles, a (seemingly) valid answer
> that is brought up is "We can wait 6 more months and have a breaking
> release that will force us to migrate painfully, let's not move yet".
>
> 3. From what I can see in the "Likely highlights" (this phrasing is
> unclear to me, you don't expect some of those changes to make it to the
> release?), it is mostly an engineering release (which is great). Do you
> think that the 9.4 series could benefit from the same longevity as the
> 8.10 did and take its place as a continuously-improved version while
> Language / R&D versions of GHC are published anew?
>
> 4. There was a talk of slowing the release schedule to once a year, and
> last I heard, Ben was sympathetic to it. Could you express the official
> position of your team on the matter?
>
> Again, I'd like to echo Richard's words in the other thread, thank you
> and your team for all this work, this is immensely appreciated.
>
> Cheers,
> Hécate
>
> Le 22/02/2022 à 18:14, Matthew Pickering a écrit :
> > Hi all,
> >
> > Firstly we are anticipating branching 9.4 in about 6 weeks time
> > (approx start of April). Most of the major features originally
> > milestoned[1] for this release have landed and the main branch is
> > currently in a nice state. This timeline will be solidified once the
> > 9.2.2 release has been completed.
> >
> > The major outstanding work that I am aware of is
> >
> > Windows toolchain work (#21019) (Ben Gamari)
> > Partial Register Stall (#20405) (Andreas Klebinger)
> > hi-haddock (!6224) (Zubin Duggal / Matthew Pickering )
> > Directed Coercions (!6476) (Sam Derbyshire)
> >
> > Secondly, we are anticipating adding a javascript backend inspired by
> > GHCJS as the highlight of the 9.6 release. This work is led by the
> > team at IOHK.
> >
> > * The planning and progress of this process is tracked on this wiki
> > page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend
> > * We anticipate reviewing and merging patches incrementally into a
> > feature branch until the point where test coverage is suitable and the
> > patches can be merged into the main branch.
> >
> > Cheers,
> >
> > Matt
> >
> >
> > [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> --
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs