On Mon, Dec 08, 2008 at 04:28:31PM -0000, Claus Reinke wrote:
> >>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
This only removes a package dep and some comments:
hunk ./Data/Array.hs 62
---import Data.Generics.Instances () -- To provide a Data instance
---import Data.Generics.Basics () -- because the Data instance is an orphan
hunk ./array.cabal 18
- if !impl(nhc98)
- build-depends: syb
I don't know if the package dep removal could have contributed to
cabal-install reinstalling array, but I suspect it's more likely that
the problem was that cabal-install wanted it to depend on base-3 instead
of base-4.
> 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
This is in the 6.10.1 release, and in the package on hackage.
> 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
The version-bumping patch doesn't determine what the contents of the
version are. Apart from anything else, patches can be reordered in
darcs. There should be a tag defining what's in the version, but it
looks like I forgot to do that this time round. I'll go back and add the
tags, but FYI they'll contain the same patches as the
GHC 6.10.1 release
tags.
> >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.
I don't think it is common for patch-level to go up for each patch,
especially in the open source world. Normally it's only bumped on each
release.
And having the version number change with each patch would be a pain to
do, and would mean that we wouldn't be able to cherry-pick patches as
they'd all depend on the previous one.
> 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?
Yes, but that won't help with the problem of cabal-install replacing an
installed version with an ABI-incompatible build of the same version.
Thanks
Ian
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
