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”.
It seems a very funny way to do it. I'd prefer to ask "what cadence do we
want" and then move on to discuss features individually. At the moment I
might think "yes, extension X belongs in the next GHC20xx", so do I vote
yes or no for X?
What do other members of the committee think about cadence? RSVP! You are
a member!
Simon
On Tue, 10 Jan 2023 at 10:13, 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@joachim-breitner.de http://www.joachim-breitner.de/