have you tried installing a newer version of containers yourself globally, and making the other one hidden? Or just making the global one ghc comes with hidden? On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton wrote:

On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka wrote:

...

* Ryan Newton [2014-01-14 11:41:48-0500]

...

Replacing containers seems like a real pain for end users

Is it a real pain? Why?

One thing I ran into is that cabal sandboxes want consistent dependencies. And when users get to this point where they need to grab our latest containers, they've got a bunch of core/haskell platform packages that depend on the old containers.

I didn't mean that there was anything difficult about containers itself, just that almost everything else depends on it.

-Ryan

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

ok, thats a good point On Tue, Jan 14, 2014 at 3:15 PM, Reid Barton wrote:

On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton wrote:

...

On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka wrote:

...

* Ryan Newton [2014-01-14 11:41:48-0500]

...

Replacing containers seems like a real pain for end users

Is it a real pain? Why?

One thing I ran into is that cabal sandboxes want consistent dependencies. And when users get to this point where they need to grab our latest containers, they've got a bunch of core/haskell platform packages that depend on the old containers.

I didn't mean that there was anything difficult about containers itself, just that almost everything else depends on it.

In addition to the general pain of updating packages at the base of the dependency hierarchy, there is also the fact that the template-haskell package depends on containers. As far as I know upgrading template-haskell is impossible, or at least a Very Bad Idea, so any library that wants to use an updated version of containers can't use template-haskell, or even be linked into an application that uses template-haskell directly or through another library.

As far as I am concerned as a GHC user, versions of containers that aren't the one that came with my GHC might as well not exist. For example if I see that a package has a constraint "containers >= 0.10", I just assume I cannot use the library with GHC 7.4. Thus I'm strongly in favor of synchronizing containers releases with releases of GHC.

Regards, Reid Barton

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

I'll make a release in the next few days. On Tue, Jan 14, 2014 at 10:33 PM, Milan Straka wrote:

Hi Johan,

I think releasing 0.5.4 is a good idea. Could I ask you to do the release as usual, please?

We added the splitRoot function, so it should really be 0.5.4 and not only 0.5.3.2. Actually, we added Functor instance to Graph.SCC and Functor and Applicative instances to Graph.SetM, but Graph is rarely used, so I would deliberately break PVP and not do a major version bump.

Thanks, cheers, Milan

...

-----Original message----- From: Ryan Newton Sent: 14 Jan 2014, 11:41

Hi guys,

I'm wondering if we can do a hackage release of 0.5.3.2? That "splitRoot" function is in there, and my ability to deploy parallel code that uses containers depends on people getting it! Are there any other changes since 0.5.3.1?

Replacing containers seems like a real pain for end users, so it would be great if 0.5.3.2 could come with GHC 7.8. Currently, it looks like the GHC repo is up to date in that it includes 0.5.3.1.

I realize it is late days for this, but:

- It's been a month since we put splitRoot in; I've been using it heavily and it I'm pretty confident that it's correct. (It's so simple!) - Nothing else is touched, so there is very little liability associated with this version bump.

And, as you know, if we don't make this round it's a long latency before the next chance. That is, before we can expect people to do parallel folds over Data.Set or Data.Map without installation headache.

Any objections? -Ryan