I can no longer maintain containers

[Bardur Arantsson]

On 04/06/2016 10:40 PM, Milan Straka wrote:
> Hi all,
> 
> personally I think that splitting containers has nearly no
> advantages, but may negatively affect many users, so I am against it.
> The details follow.
> 
> It is true that containers consists of unrelated data structures, but
> many data structure libraries do, and I do not believe that is should be
> a reason to split the package. Also I feel that containers are quite
> small.
> 
> From the user point of view, I doubt people would appreciate having more
> fine-grained versioning of parts of containers. Also note that it is
> difficult to use other version of containers than the one bundled with
> GHC (hm, template-haskell used to depend on bundled containers, but at
> least in 7.10 it does not anymore -- only Cabal, binary, ghc, haskeline,
> hoopl and hpc does; the situation is better that it used to), so
> incremental releases of containers between GHC releases have (had?)
> little use.
> 
> From the maintainer point of view, I think building/testing of
> containers is fine, as the library is pretty small and (at least from my
> point of view) builds reasonably fast. Moreover, as containers are
> _widely_ used, I believe we should make as little backward incompatible
> changes as possible, so bundling releases with GHC releases is fine (and
> therefore little would be gained from having three smaller packages).
> 
> Splitting the package may cause problems -- some people think so, some
> think that the problems are recoverable -- but still, it is probable
> that some issues will appear and these may affect a lot of users.
> 

+1

(FWIW, personally a split wouldn't bother me, but then I only have a few
packages on Hackage.)

Given that "containers" already has a huge number of revdeps, the
decision to split can always be revisited at a later time without much
extra cost. (I mean, if $THE_WHOLE_WORLD_2016 depends on containers now,
it's probably not *that* much more effort to split if
$THE_WHOLE_WORLD_2018 depends on it. I'm assuming that *some* sort of
compatibility shim/package would have to be provided regardless.)

Regards,