Push new version to Hackage

[bgamari]

Currently the version on Hackage does not compile with GHC 7.6.

[akaspin]

Bump

[jtdaugherty]

In order to push a new release to Hackage, we need to be sure cabal-dev works on the two most recent Haskell Platform releases in addition to GHC 7.6. It's pretty clear that we have GHC 7.6 out of the way. Care to help us out and test on HP 2012.4.0.0 and HP 2012.2.0.0? Also, it needs to be tested on at least Linux and Windows, with OS X being valuable, too.

[etrepum]

Well, the current hackage version definitely does not work on OS X with HP 2012.4.0.0 prior to this commit https://github.com/creswick/cabal-dev/commit/80d7bc3c3ceef9deb9189cea87fb1fe3e50d6b4f#cabal-dev.cabal

Installing from source (415351d2) appears to work fine (ghc 7.4.2, HP 2012.4.0.0, Mac OS X 10.8.2, used homebrew to install ghc and haskell-platform)

$ git clone https://github.com/creswick/cabal-dev.git && (cd cabal-dev; cabal install)
Cloning into 'cabal-dev'...
[…]
Linking dist/build/cabal-dev/cabal-dev ...
Installing executable(s) in /Users/bob/.cabal/bin

[etrepum]

Just my opinion, but I think you should probably just push what you have now. If you broke HP 2012.2.0.0 on some platform, I'm sure you'll hear about it eventually. Keeping up with HP 2012.4.0.0 and newer GHC is probably much more important, people with old versions can always target some old version of cabal-dev on hackage until any backwards compatibility issues are sorted out.

[spockz]

I concur with etrepum, it is very inconvenient not to be able to build cabal-dev on a fresh HP2012.4.0.0 install.

[etrepum]

@jtdaugherty in #91 you mentioned that "some tests are failing" and this is the reason why there hasn't been a new release. Where can we find out more about the tests that are failing?

[jtdaugherty]

You can find out by running this from the root of the repository:

$ bin/runtests

[etrepum]

@jtdaugherty the failures seem to be timing related, probably cabal-dev is being executed in parallel with itself. I'll dig a bit deeper and submit a PR once I've figured it out.

[etrepum]

On further inspection, I believe that 00-index.cache is the problem in addSourceStaysSandboxed. Here's what I think is happening (all during the same second, let's call it M):

• 00-index.tar is created with an empty index (withTempPackage), this file has an mtime of M.
• 00-index.cache is created during the install that is expected to fail (withCabalDev assertExitsFailure ["install", pkgStr]). This file is empty and has an mtime of M.
• 00-index.tar is updated with the new package (withCabalDev assertExitsSuccess ["add-source", packageDir])), the mtime does not change since the clock is still at M. The problem is here, 00-index.cache still exists and is still considered to be valid but it's actually stale (and empty).
• The test fails at withCabalDev assertExitsSuccess ["install", pkgStr, "--verbose=" ++ showForCabal v] because the (empty) 00-index.cache is incorrectly considered to be valid since it has the same mtime (M) as 00-index.tar.

I think any operation that updates 00-index.tar should probably just remove the cache file. Also, this appears to be a cabal-install bug, not a cabal-dev bug. My recommendation would be to include a workaround in the test suite for cabal-dev (e.g. manually delete or refresh the cache after the add-source) and file a bug against cabal-install.

[ghost]

bump