Breaking Changes and Long Term Support Haskell

[Jeremy]

Henrik Nilsson-2 wrote
> Jeremy wrote:
> 
>  > 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.
> 
> With respect, and without commenting on the merits of the proposal that
> is then outlined (Long-Term Support Haskell), I don't think this is
> an accurate description of the two main positions in the debate at all.
> 
> Most of those who have argued against MRP, for example, have made it
> very clear that they are not at all against any breaking change. But
> they oppose breaking changes to Haskell itself, including central
> libraries, as defined by the Haskell report, unless the benefits are
> very compelling indeed. 

With equal respect, I stopped following the MRP thread when its length
exceeded my interest, so my comments may not be applicable here :-)

The LTS solution should work as long as all (or at least a big enough
majority) agree that the benefits of a  change are desirable, but disagree
as to the cost of breaking change. It allows the "nice idea but don't keep
breaking my code" people to co-exist with the "nice idea let's do it"
people.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Monad-of-no-return-Proposal-MRP-Moving-return-out-of-Monad-tp5818567p5820461.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.