Hi Committee, when we defined the process for GHC20xx, as written in https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-gh... 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@joachim-breitner.de http://www.joachim-breitner.de/