# 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:** 2

<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 3, 2023, 11:46am UTC](https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745/2 "2023-02-03T11:46:14Z")

</div>

> [@GHC 9.6 Migration Guide](http://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/5):
>
> GHC frequently fixes bugs with the side effect that code that was (accidentally) relying on the bug ceases to work. Volunteer contributors aren’t going to be pleased if every patch that fixes a bug also has to introduce a warning, retain/test the old code path for two versions, etc. and it seems like it would lead to a significant increase in the internal code complexity. Basically I don’t think it is feasible to have GHC maintain bug-for-bug compatibility between versions without a very substantial increase in the resources going in to maintenance.

I don’t follow. Other compilers do exactly that. This issue [Tracking issue for `illegal_floating_point_literal_pattern` compatibility lint · Issue #41620 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/41620) is one of many reads about how e.g. rust handles backwards compatibility breaking changes (and you could argue there as well that it’s a _bug_).

Complaining about resources is welcome, but I’m not sure it’s enough of an argument. It’s about goals. The GHC team could very well declare this as a goal and then talk to industry backers, contributors and HF whether there will be financial or manpower funding.

But it does not appear to be a goal, at least according to the [medium-term priorities](http://discourse.haskell.org/t/ghc-medium-term-priorities/5600). In section “Insufficient Resources” it’s not listed. In the section “Breaking Changes” it’s said that those are the responsibility of the **GHC Steering Committee**. But I don’t think the GHC Steering Committee rules over release management and deprecation cycles, or does it?

I think this requires more clarity.

---

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