Re: Abstract FilePath Proposal

On 07/05/2015 12:27 AM, Brandon Allbery wrote:

On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson wrote:

...

Yes, the rest of the ecosystem may move along and use the latest new shiny, but then you can always use the packages that worked with GHC 7.8.x thanks to version ranges.

Am I missing something?

Updates needed to fix e.g. security issues, which otherwise might not be backported if others are staying close to current. This is why Stackage has both LTS and Nightly; LTS only works if there's a *commitment* to it, at the level of the community for a community resource or at the level of the provider for something like ghc or Stackage.

How often have security issues with GHC (or the base libraries) itself been a problem? (In practice, I mean.) In my hypothetical scenario, there's nothing to prevent a release of GHC 7.8.(x+1) while GHC 7.12. is the new thing. Nor does anything prevent library releases of my-library-1.2.x (security patch) while my-library-1.6.x is the hot new thing.

Note that GHC HQ's response was that they have had problems finding people to keep multiple versions active at the same time; it's a significant job given that backporting (say) a fix to a type system issue allowing unexpectedly unsafe code (say, https://ghc.haskell.org/trac/ghc/ticket/9858) can mean a complete redesign of the patch, if the one in HEAD relies on other changes that can't be sensibly backported.

Yes, there's a man-power problem... but that isn't going to be solved unless some people/companies step up to the plate. Preferably the people who are actually using/relying on those old versions. This is no different from e.g. RHEL/Ubuntu LTS/Debian in the Linux world. (Well, except RHEL actually has a revenue stream that means that they can and do support old versions of various things.) Regards,