There seems to be a fair amount of friction between those who want to introduce new features or fix significant historical warts in the base libraries - even if this requires breaking changes - and those who insist on no significant breaking changes in new releases, regardless of the reason or how much warning was given. The rest of the industry has already solved this with long-term/extended support releases. Some version of the platform is blessed with long-term support, and will continue to receive bug fixes and security patches for a number of years, but no other changes. This solution exists for Haskell as well, in the form of Long-Term Support Haskell (https://github.com/fpco/lts-haskell/blob/master/README.md) by FP Complete. Not only GHC but an entire ecosystem of libraries are frozen when a new LTS version is released and only bug/security fixes are allowed going forward. Users requiring long-term stability over new features could use LTS Haskell, while those who accept some fixing up of old code to gain new features (or remove old warts) can uses the latest GHC and Hackage. The only deficiency I can see in this is that FP Complete don't seem to provide any guarantees as to how long they will continue maintaining any LTS release. However, this is only relevant to bug fixes which tend to taper off after a while anyway - the actual release is available for perpetuity. Perhaps they could provide a commercial service with guarantees of bug-fixes for x years? -- View this message in context: http://haskell.1045720.n5.nabble.com/Breaking-Changes-and-Long-Term-Support-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.