<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
Another year has passed, and if we are serious with the idea that<br>
GHC20xx is a continuous thing, we should probably start defining<br>
GHC2023 – even if it is just a small delta. <br></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Indeed, we originally said we'd review GHC20xx annually, but I think we might want to consult the community to see if that is too often. There has been an <a href="https://discourse.haskell.org/t/quo-vadis-ghc2023/5220">interesting thread </a>on the Haskell Discourse.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The HF Stability Working Group discussed this on Monday, and I think Tom Ellis (a member of the SWG) is willing to lead a consultation. I think that would be great -- we have no axe to grind here, and I think we'll be delighted to do whatever makes the maximal number of people happy.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Tom (cc'd) will write with more info shortly. Sound OK?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Committee,<br>
<br>
when we defined the process for GHC20xx, as written in <br>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst</a><br>
we wrote<br>
<br>
Likely, the first iteration of this process will be vastly different<br>
from the following ones: The first one is expected to add a large<br>
number of uncontroversial extensions; so the next iteration will<br>
likely only make a smaller, but more controversial change.<br>
<br>
Therefore, this proposal does not commit to a fixed cadence.<br>
Instead, 6 months after the first release of a version of GHC that<br>
supports a GHC20xx set, we evaluate the outcome, the process, and<br>
the perceived need of a next release. At that time we will refine<br>
the processes, if needed, and set a cadence.<br>
<br>
The first version of GHC that supported GHC2021 was 9.2, released in<br>
October 2022.<br>
<br>
Last fall we said that not enough time has passed to do such an<br>
evaluation, and we skipped defining GHC2022.<br>
<br>
Another year has passed, and if we are serious with the idea that<br>
GHC20xx is a continuous thing, we should probably start defining<br>
GHC2023 – even if it is just a small delta. This e-mail tries to<br>
kickstart that process.<br>
<br>
<br>
Last time we did a relative elaborate thing where we voted on<br>
essentially _every_ extension. I think that made sense for the first<br>
iteration, where we had to winddow down the likely extensions. But now<br>
we have a base line (GHC2021), and are asked to find a suitable delta,<br>
and I’d go for a nomination-based approach: Committee members can<br>
propose adding (or removing, in theory) specific extensions, and then<br>
we vote only on those. Does that sound reasonable?<br>
<br>
Does anyone have any insight from the real world? Has GHC2021 helped<br>
our users? And if not, why not?<br>
<br>
What kind of hard data would you like to see, if any?<br>
<br>
(I’m a bit wary of spending too much time writing scripts to scrape<br>
hackage, for example to see which extensions people tend to enable _in<br>
addition_ to GHC2021, only to see that libraries on hackage are<br>
understandably slow to use default-language: GHC2021, as that’s not<br>
great for backward compat for now. But I am also not sure where to look<br>
for good data…)<br>
<br>
Cheers,<br>
Joachim<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>