Abstract FilePath Proposal

[Bardur Arantsson]

On 07/05/2015 12:27 AM, Brandon Allbery wrote:
> On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson <spam at scientician.net>
> 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,