# Language, library, and compiler stability (moved from GHC 9.6 Migration guide)

**URL:** <https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745>\
**Category:** Uncategorized\
**Created:** [February 4, 2023, 4:00pm UTC](https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745 "2023-02-04T16:00:25Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [February 4, 2023, 5:25am UTC](https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745/7 "2023-02-04T05:25:40Z")

</div>

> [@shf](#):
>
> It depends on the nature of the problem.
> 
> Looking through Rust compiler release notes, I found several examples of breaking bugfixes without any intermediate releases introducing compatibility warnings, so it’s not as simple as “Other compilers do exactly that”.

Sure, but let’s not pretend we’re anywhere near what rustc does:

1. there is a very strict 3-steps procedure wrt breaking changes that can take years
  - introduce a lint
  - make the lint deny by default
  - make it a hard error

2. breaking changes are widely discussed in the community before they’re introduced via the above procedure (also may take years)
3. there’s a strong motivation by the compiler team to keep backwards compatibility

I don’t think we have any of those points implemented. That was my point, not whether the current breakage in 9.6 would require a deprecation procedure or not.

This difference is very stark and should serve as a reference point when discussing diverging goals in our community.

---

_[View the full topic](https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745)._