[ghc-steering-committee] Stability

[Simon Marlow]

On Fri, 13 Oct 2023 at 10:39, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

>
> But here's the thing: I claim that GR{1-3} aren't going to solve the
> stability problem. I'm confident about this because they're already the
> policy. And while it's not entirely impossible to imagine that writing them
> down more prominently will solve the problems that we have, I don't believe
> we should count on it. So anyway, we've been having this policy, have we
> failed to apply it? Why? Or maybe the reason why stability is a concern is
> because of reasons that aren't caught by this policy, then what is missing?
> I'm asking these questions in earnest: I really don't know. And I don't
> think we'll actually make significant progress without getting answers to
> these questions.
>

It's already the policy in the sense that when we break stuff, we generally
have a deprecation cycle. But where GR2 diverges from the current
(informal) policy is in judging when it's OK to make a breaking change. GR2
- at least in my interpretation of it, and perhaps we should make this
clearer - requires that to make a breaking change we have to be forced
somehow. Because there's a bug that needs fixing, or because the current
behaviour is broken for some reason. We're not going to make a breaking
change just because the change would make things better, even with a
deprecation cycle: those kinds of changes will still be possible, but
they'll go behind a new language extension flag and/or into the next
GHC20xx, so the user has control over when they have to adapt their code.

It's probably true that a majority of the backwards compatibility issues
encountered with a GHC upgrade come from changes in third-party packages.
But in order to decouple the compiler upgrade from package upgrades, we
have to make all the existing packages compile with the new GHC, so
stability has to start with GHC itself.

Incidentally I'd like the stability policy to be extended to compiler and
runtime flags - i.e. don't gratuitously change the behaviour of existing
flags or remove them. Extend stability to build systems, not just code.
This is much harder than language changes because we don't have extensions
or GHC20xx, but we can do deprecation cycles.

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231013/4496c27e/attachment.html>