Breaking Changes and Long Term Support Haskell

[Jeremy]

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-Haskell-tp5820429.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.