Could the array/containers version bumps be done soon, please,
As far as I can see there are no code changes in the array package. I
guess what we're really trying to do is work around cabal-install
replacing libraries with ABI-incompatible builds?
array had dependency/import changes since the last version change,
same for containers, which also had export changes:
------------------------------------array
Thu Nov 13 14:48:43 GMT Standard Time 2008 Duncan Coutts <duncan haskell.org>
* Turns out syb is not needed at all
M ./Data/Array.hs -2
M ./array.cabal -2
Thu Oct 2 09:24:11 GMT Daylight Time 2008 'Jose Pedro Magalhaes <jpm
cs.uu.nl>'
* remove unnecessary Data.Generics.* imports
M ./Data/Array.hs -2 +2
Sat Sep 20 16:57:39 GMT Daylight Time 2008 Ian Lynagh <igloo earth.li>
* Bump version number to 0.2.0.0
M ./array.cabal -1 +1
------------------------------------containers
Fri Oct 24 15:39:49 GMT Daylight Time 2008 Ian Lynagh <igloo earth.li>
* Doc fix, from hackage trac #378
M ./Data/IntSet.hs -1 +1
Sun Oct 5 01:25:59 GMT Daylight Time 2008 Ross Paterson <ross soi.city.ac.uk>
* import Data.Data instead of Data.Generics.*, eliminating the dependency on
syb
M ./Data/IntMap.hs -2 +1
M ./Data/IntSet.hs -2 +1
M ./Data/Map.hs -2 +1
M ./Data/Sequence.hs -1 +1
M ./Data/Set.hs -2 +1
M ./Data/Tree.hs -2 +1
M ./containers.cabal -2
Thu Oct 2 22:54:38 GMT Daylight Time 2008 sedillard gmail.com
* fixed typo in highestBitMask
M ./Data/IntMap.hs -2 +2
Mon Sep 22 22:32:00 GMT Daylight Time 2008 qdunkan gmail.com
* export Data.Map.toDescList, foldlWithKey, and foldrWithKey (trac ticket 2580)
toDescList was previously implemented, but not exported.
foldlWithKey was previously implemented, but not exported. It can be used to
implement toDescList.
foldrWithKey is already exported as foldWithKey, but foldrWithKey is explicitly
the mirror of foldlWithKey, and foldWithKey kept for compatibility.
M ./Data/Map.hs -20 +23
Sat Sep 20 17:00:16 GMT Daylight Time 2008 Ian Lynagh <igloo earth.li>
* Bump version number to 0.2.0.0
M ./containers.cabal -1 +1
------------------------------------
We could do that by bumping the 4th component of each library, so that
that version isn't on hackage and thus cabal-install can't replace it.
that sounds similar to a patch-level, only that it isn't, if it isn't going up
with each patch. Does cabal allow for labels in version numbers, to
indicate an unstable version phase (-head/-unstable)?
However, once the VCS changeover happens the plan is to use released
versions of all the libraries, which means that we can't do that (unless
we mangled their version numbers or something).
Won't every released version have its own number anyway?
>Ian - I think this might be different from the policy we agreed before,
>but I can't remember where (if anywhere) we wrote it down. The difference
>is that we hadn't considered the possibility of people trying to use cabal
>install with a an unreleased HEAD build before, but I don't think there's
>a good reason why this shouldn't work.
I think there are lots of reasons why released packages on hackage might
not work with an unreleased compiler and libraries, but if we can make
things better with little extra effort then I agree that we should do
so.
Thanks,
Claus
So, what's the best way forward? Bump the 4th component of all the
libraries now, and make cabal-install better behaved before the VCS
switchover?
Thanks
Ian
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
