[ghc-steering-committee] GHC20xx review; GHC2022 yes or no?

[Joachim Breitner]

Right, I thought it wasn't, and phrased the mail accordingly. But then I noticed that the timeline in https://gitlab.haskell.org/ghc/ghc/-/milestones/365 said 2021, not 2022, and that it already is in nixpkgs, so I drew the wrong conclusions, and changed my mail again

Anyways even more the reason to skip GHC2022


05.10.2021 23:50:06 Richard Eisenberg <lists at richarde.dev>:

> What makes you say 9.2 has been released? I don't think it has been. https://www.haskell.org/ghc/download.html does not list it, for example.
> 
> Otherwise, I agree on holding off.
> 
> Thanks for raising this!
> Richard
> 
>> On Oct 5, 2021, at 3:50 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Hi Committee,
>> 
>> when we defined the process for GHC20xx, as written in
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
>> we wrote
>> 
>>   Likely, the first iteration of this process will be vastly different
>>   from the following ones: The first one is expected to add a large
>>   number of uncontroversial extensions; so the next iteration will
>>   likely only make a smaller, but more controversial change.
>> 
>>   Therefore, this proposal does not commit to a fixed cadence.
>>   Instead, 6 months after the first release of a version of GHC that
>>   supports a GHC20xx set, we evaluate the outcome, the process, and
>>   the perceived need of a next release. At that time we will refine
>>   the processes, if needed, and set a cadence.
>> 
>> The first version of GHC that supported GHC20xx is 9.2, released in March.
>> So we should do this evaluation now.
>> 
>> My impression is that 9.2 hasn’t reached the masses yet:
>> NixOS stable doesn’t even have it, and the default is at 8.10.
>> Stackage LTS is at 8.10, and nightly at 9.0
>> Debian is at 8.8.
>> 
>> So it seems premature to try to evaluate its impact, and what, if
>> anything, we should do differently for a hypothetical GHC2022.
>> 
>> So I suggest we postpone this review for another half year or so.
>> 
>> Also, I don’t see why GHC2022 would be different than GHC2021. Not that
>> much has changed about GHC and its set of “should-be-default”
>> extensions since last year, has it?
>> 
>> So I suggest we don’t work on defining GHC2022, and the next update
>> will be GHC2023 (or later).
>> 
>> 
>> What do you think,
>> 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