[ghc-steering-committee] Call for votes: Shall we have GHC2023

[Chris Dornan]

I agree that we should release GHC2023 for all the reason Joachim says. Each GHCXXXX release is just our declaration of the extensions that we think should be enabled by default. It is going to change as we larn more about the extensions, let's clean as we go and make an annual statement of our recommended Haskell brew. If we are not prepared to spend a bit of time thinking about whether we recommend extensions we have already defined then that, to me, suggests something is off.

What do you say Joachim to publishing schedule for proposing additions (and deletions) and then voting on them. I was think we could take the year but having a 9.8-friendly schedule makes sense.

Anyway my vote is for yes to GHC2023.

Chris

> On 2023-01-22, at 12:57, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> unsurprisingly, I vote
> 
> Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
>>   Should we proceed towards GHC2023?
> 
> Yes!
> 
> 
> Brief summary of why:
> 
> * One goal of GHC20xx was to fix one problem we had with the
>   Haskell20xx process: New releases were rare, small and eventually
>   stopped. So I want GHC20xx to not fall in the same trap of being
>   over-cautious when making releases.
> 
> * A early and small(!) (e.g. just adding role annotations) release 
>   gives both us and the community a chance to practice. It is a good
>   way to learn that new GHC20xx releases are _not_ a big deal, and
>   those users who upgrade will learn that upgrading is (well, can be)
>   totally painless. I’d like to let them have such a positive
>   experience.
> 
> * Assuming that every GHC20xx is “better” in some sense than the 
>   previous, and even if it is just mild QoL improvements, I see little
>   gain in holding that back longer than necessary.
> 
> * GHC20xx releases are lower pain than GHC releases or base changes!
> 
>   A new version of GHC you _have_ to upgrade to get important fixes. 
>   A new version of base you _have_ to upgrade to, else you cannot get
>   new versions of your dependencies. These upgrades are forced on the
>   user, with only limited wiggle room.
> 
>   A new GHC20xx is totally optional. Your -XGHC2021 code will just 
>   continue to work as you upgrade GHC. So if it is _less_ disruptive,
>   why have a longer cadence?
> 
>   Or, as a friend of mine nicely put it: Even if there are users out 
>   there that are best served by having GHC2021, GHC2024, GHC2027…, 
>   they are free and welcome to only bump their edition every three
>   years. Also having GHC2023 and GHC2025 … does not in any way impact
>   them.
> 
>   So because of their opt-in, usually-pinned nature, backward compat
>   worries need not restrict us here, I’d say.
> 
> 
> Hence I’d like to define a GHC2023 (in time for GHC 9.8?). And I
> wouldn’t worry about a _fixed_ cadence until we had two or three
> releases and learned from it.
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee