[ghc-steering-committee] GHC2023

[Joachim Breitner]

Hi,

Am Dienstag, dem 10.01.2023 um 10:06 +0000 schrieb Simon Peyton Jones:
> > So let’s bring this to a vote – if the camp that prefers even rarer
> > releases is in the majority, the vote will show that. 
> > 
> 
> Well, it will if that's what we vote on, but you are suggesting 
> …
> Can we vote on that first?

That’s part of the vote – just don’t say “strong yes” for any option if
you think it’s too early. “Strong yes” means “I think there should be a
GHC2023 because of extension X”.
If a majority votes at most “weak yes” to every extension, then there
will be no GHC2023.

I find a separate vote “should we have GHC2023” is not that meaningful
if it would be equal to GHC2021 anyways (assuming no extenion gets then
voted in) so it seems prudent to ask “Is there even any extension that
warrants having GHC2023.”

>  I'd just every 3 yrs, which appears to match Rust.

I think the comparision is misleading. Rust bundles _breaking_ changes
every 3 years. Nonbreaking, purely additive, syntax guarded, features
come out continuously. If we follow their model, we can have GHC20xx
yearly (or more often!), as long as we hold back _breaking_ changes to
a three-yearly cadence. (Which seems quite a reasonably policy.)

Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/