Hello Discourse!
You can check out the minutes and agenda for the Board meeting that took place on the 2021-11-18
Have a nice week-end!
Hello Discourse!
You can check out the minutes and agenda for the Board meeting that took place on the 2021-11-18
Have a nice week-end!
@Kleidukos thanks for the update. On the release cycle. I’ll keep repeating what I’ve said before. We should have tick-tock cycles. Every other release should be purely engineering improvements with no visible breaking changes. We used to have yearly cycles, so we jammed all kinds of changes into yearly updates, and we had breakage only once a year. Now we have a higher release cadence, but we still jam in breaking changes into each release. While I acknowledge the language needing to move forward, I believe we should have dedicated improvement releases only.
Stuff that would go into those would be:
And not add language features into those releases.
I think it would also help the GHC team to focus exclusively on ghcs engineering challenges without having to deal with the introduction of new language features.
The churn should be zero. You’ll get a generally improved compiler with fewer bugs, but the language stays the same. Your old code compiles as is, maybe a bit fast, maybe to a new target, maybe it even runs faster, maybe you get support for additional profiling tools. Do we even need to update base
? Maybe not, new version bounds? Probably not.
Maybe it is obvious but i want to stress that it also should include (and it should focus on) bug fixes introduced by breaking changes of the previous releaseprevious releases
EDIT: mentioned with You’ll get a generally improved compiler with fewer bugs
but still
Yes. This should also include bugfixes (that do not impact the language surface). If a feature is broken beyond repair, the temporary fix could be to issue a warning during compilation, and it’s use be discouraged for the time being, and the feature be “properly” fixes in the next language level release.