Releasing containers 0.5.3.2 -- before GHC 7.8?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Ryan Newton
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/e609a42c/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Roman Cheplyaka-2
* Ryan Newton <rrnewton at gmail.com> [2014-01-14 11:41:48-0500]
> Replacing containers seems like a real pain for end users

Is it a real pain? Why?

I just tried 'cabal install containers', and it went flawlessly.

To make it clear, I'm not in any way opposed to containers upgrade, but
that phrase struck me as odd.

The only issue I'm aware of is related to the GHC API, but
high-performance parallel algorithms and the GHC API are rarely used
together in the same project.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/b6170b9f/attachment-0001.sig>

Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Ryan Newton
On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

> * Ryan Newton <rrnewton at gmail.com> [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/3b6f54b9/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Carter Schonwald
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 <rrnewton at gmail.com> wrote:

>
>
>
> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma at ro-che.info>wrote:
>
>> * Ryan Newton <rrnewton at gmail.com> [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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/a8297785/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Reid Barton-2
In reply to this post by Ryan Newton
On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnewton at gmail.com> wrote:

> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma at ro-che.info>wrote:
>
>> * Ryan Newton <rrnewton at gmail.com> [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/370ce00a/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Carter Schonwald
ok, thats a good point


On Tue, Jan 14, 2014 at 3:15 PM, Reid Barton <rwbarton at gmail.com> wrote:

> On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma at ro-che.info>wrote:
>>
>>> * Ryan Newton <rrnewton at gmail.com> [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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/dabcb417/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Johan Tibell-2
In reply to this post by Ryan Newton
I'll make a release in the next few days.


On Tue, Jan 14, 2014 at 10:33 PM, Milan Straka <fox at ucw.cz> 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 <rrnewton at gmail.com>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/d622d594/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Releasing containers 0.5.3.2 -- before GHC 7.8?

Herbert Valerio Riedel
In reply to this post by Ryan Newton
On 2014-01-14 at 17:41:48 +0100, Ryan Newton wrote:
> 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.

Done (actually is do.. erm... containers-0.5.4.0):

http://git.haskell.org/ghc.git/commitdiff/69cf5c4cb8aba309e5c495008b69089e5431a095

Cheers,
  hvr