Proposal : early warning system for breaking changes in the core libraries

[ocramz]

Seeing that:

• the Haskell core libraries will keep evolving for the foreseeable future; due to new features and bugfixes in GHC, due to people wanting better interfaces, etc.
• some of these changes are backward-incompatible : for a current list of scheduled breaking changes, see https://github.com/fumieval/Haskell-breaking-changes/tree/d0ac926e8b5ca36f19570396d4b59a91c577784a by @fumieval
• breaking changes cause huge disagreement and trauma in the community: "why should updating dependencies break my code"? see the recent "No Eq in /=" debate :
  • Proposal: Remove method (/=) from class Eq #3
  • https://discourse.haskell.org/t/learning-from-the-no-in-eq-debate/3651
• some of these changes are part of a multi-year, multi-version migration plan (e.g. the "Monad of no return" saga https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return , or "Semigroup as superclass of Monoid" ), which might make it harder to see the forest from the trees of any specific change in a point release ("why now?")
• deprecation warnings in the code don't apply to all Haskell syntactic elements, e.g. CPP, Template Haskell splices etc.
• systematic mitigation strategies (e.g. refactoring/migration tools) are still being invented and discussed

I think all this points to a communication issue; we need a way for breaking changes to be advertised (and motivated) in such a way that everyone can see the whole picture. I think the mailing lists and forums are too noisy a medium for this.

Proposal :

• early warnings are issued only after the CLC has made a decision on a breaking change
• things are written to the early warning system only by the CLC and/or appointed people
• highly visible announcements board : e.g. a dedicated page "Early warnings" on the GHC wiki : https://gitlab.haskell.org/ghc/ghc/-/wikis/home or right under the haskell.org homepage
• not a peanut gallery : when an Early Warning is issued, discussion and commentary already happened (hopefully) on the corresponding Github/Gitlab tickets

cc @emilypi @myShoggoth @simonpj @goldfirere

Closely related:

• GHC release candidates and/or GHC developer preview (cc @Kleidukos @cdsmith )

Out of scope:

• what/why is a core libraries breaking change : Decide on core principles against which to judge breaking changes #12
• strategies for minimizing breakage

Thank you for reading, I look forward to all feedback on this.

[chreekat]

Huge +1. As a peanut gallerian, the Eq of No Neq thing came as no shock to me because I subject myself to notification emails on all the RFC repos and could see the evolution of the proposal. (I was surprised, but not shocked.) Most people don't do that. They didn't know how much rational discussion had already gone into it, and they didn't know how quickly it would affect them.

I'm not sure if this the same idea or a different one, but I think the tone of an announcement is also important. I get the feeling that most people felt they had no chance to share their thoughts or give feedback — they just learned "Eq is getting a breaking change". We can't prevent all of that, but it could be acknowledged and softened if the message was, "We think this breaking change is worth it. Please now let us know if it causes you any special trouble, and we will try to accommodate you."

[hasufell]

Reading #12 (comment) suggests that announcements and even release notes aren't really going to save peoples time though, which was the issue raised by most of the voices.

I think all this points to a communication issue; we need a way for breaking changes to be advertised (and motivated) in such a way that everyone can see the whole picture.

This repo already serves as the backlog for both decisions and discussion, no? I'm not sure if yet another place to look for changes will really improve visibility. There could simply be a summary in the README.

[goldfirere]

My initial impression was that this was a communication issue as well -- both in informing the community of upcoming changes and also in fostering communication from the community about changes being considered. But @simonmar's post #12 (comment) educated me a bit, stressing that time mitigation is perhaps more important than communication.

People use Haskell because it's awesome, and it's awesome because of all the research and development that goes into it. It is thus a natural consequence (to me) that it will continue to evolve -- unless we make a decision to stop that research and development (which would, in my opinion, make it less awesome over time). So people who use Haskell expect some churn. (Perhaps some don't -- if that's the case, we do have a communication issue to solve.)

This analysis suggests that we focus on two mitigations:

1. Clearly advertise what the expected churn is. For example: How often do we push out breaking changes? If there is, say, a critical security fix, how far back do we backport it? Do we have a "no CPP" policy? How stable are warnings / deprecations? By articulating this, we can inform adopters how they should expect to accommodate Haskell, by planning to (say) stick with a given GHC version for 2 years before upgrading and then devoting time to perform the upgrade.

2. Think about ways to save people time. Despite some pessimism around the ability for tooling to help (and I see where this pessimism comes from), I do think there is opportunity for improvement here. Recent work within GHC (championed by @alanz) makes this more possible today than it ever has been.

Interestingly, neither (1) nor (2) directly suggest that we do what is requested at the top of this ticket (the early warning system). I think an early warning system would be indeed good. But I suspect that my (1) and (2) will be more effective in aiding adoption (and preventing attrition).

[Bodigrim]

As I said elsewhere, despite EqOfNoNonEq proposal churn, in general CLC is responsible only for minority of breakage in Haskell ecosystem. We will upload migration guides for breaking changes caused by CLC under https://github.com/haskell/core-libraries-committee/tree/main/guides, which I believe provides a reasonable visibility.

An issue tracker with a wider scope (e. g., including GHC breaking changes) could be useful, but goes far beyond CLC mandate and capabilities. I believe this better falls under recently created HF Stability Working Group, which has been discussing exactly such possibility. CC @cdornan.

[cdornan]

Yes indeed -- we are looking into just this, but for all the things that could disrupt the key components of the ecosystem.

[Ericson2314]

Insofar that this needs tech at all, I think https://discourse.haskell.org/t/pre-hftp-decoupling-base-and-ghc/3727 is the right approach.

The current approach to finding ecosystem breakage outlined in #10 (comment) in fact does involve modifying the base for a released compiler, to avoid confounding other sorts of breakage from GHC "head". With GHC and base decoupled, this would become a more regular process, as we would both test new features in base for existing GHCs and actually release those features to existing GHCs, all in the same way.

[Bodigrim]

I believe HF Stability Working Group will announce further steps in this direction in due course and the issue will be dealt outside of CLC. Closing to keep the issue list CLC-actionable, but feel free to continue the discussion.