On Sat, Feb 09, 2013 at 12:20:22AM +0100, Henning Thielemann wrote:
On Fri, 8 Feb 2013, Ian Lynagh wrote:
On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote:
On 03/02/13 20:48, Simon Marlow wrote:
On 02/02/13 14:11, Ian Lynagh wrote:
The unix version number is still 2.6.1.0, but doesn't the new policy http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages
mean that it should be bumped to 2.7.0.0 now?
Actually, having just tried to do this, I'm not sure how it's meant to work in practice.
Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet;
Right, that's why you don't release the modified Cabal and haskeline packages to Hackage until a new release of GHC.
If upstream has applied a patch relaxing the bounds months before the GHC release, then there is a good chance it will end up in a release that gets uploaded to Hackage. Actually, I think that it's generally prefered that we only use released versions of libraries that have upstreams, in which case uploading it to hackage would be /encouraged/.
No, because with the old scheme there were two different versions of the same package with the same version number. That is, there was unix-2.6 on Hackage and unix-2.6 in a nightly build, but both archives had different content.
Nightly builds don't generally contain released versions of libraries. Even with the new version bumping scheme, 2 different nightly builds might have different code but the same version number. Thanks Ian