Hi, unsurprisingly, I vote Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
Should we proceed towards GHC2023?
Yes! Brief summary of why: * One goal of GHC20xx was to fix one problem we had with the Haskell20xx process: New releases were rare, small and eventually stopped. So I want GHC20xx to not fall in the same trap of being over-cautious when making releases. * A early and small(!) (e.g. just adding role annotations) release gives both us and the community a chance to practice. It is a good way to learn that new GHC20xx releases are _not_ a big deal, and those users who upgrade will learn that upgrading is (well, can be) totally painless. I’d like to let them have such a positive experience. * Assuming that every GHC20xx is “better” in some sense than the previous, and even if it is just mild QoL improvements, I see little gain in holding that back longer than necessary. * GHC20xx releases are lower pain than GHC releases or base changes! A new version of GHC you _have_ to upgrade to get important fixes. A new version of base you _have_ to upgrade to, else you cannot get new versions of your dependencies. These upgrades are forced on the user, with only limited wiggle room. A new GHC20xx is totally optional. Your -XGHC2021 code will just continue to work as you upgrade GHC. So if it is _less_ disruptive, why have a longer cadence? Or, as a friend of mine nicely put it: Even if there are users out there that are best served by having GHC2021, GHC2024, GHC2027…, they are free and welcome to only bump their edition every three years. Also having GHC2023 and GHC2025 … does not in any way impact them. So because of their opt-in, usually-pinned nature, backward compat worries need not restrict us here, I’d say. Hence I’d like to define a GHC2023 (in time for GHC 9.8?). And I wouldn’t worry about a _fixed_ cadence until we had two or three releases and learned from it. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/