On 08/02/13 23:05, 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; perhaps by the time it is released it will not work with the current Cabal/haskeline code.
So a good solution to this would be to have two version bumps: one for development (2.7.x.x) and another bump for the final release (2.8.0.0). Then Cabal can make releases that relax the unix dependency to 2.7, which is fine because we'll never make a release of 2.7, it just keeps things working during development.
The other way is to make local ghc-only changes to relax the dependencies, but that would increase the risk that we'd release with a ghc branch of the library by mistake.
Wouldn't it be better to go back to the previous scheme, where we didn't update version numbers until release time?
There were serious problems with that scheme too, which is why we changed. We get into a situation where people can't test HEAD because some packages don't work with it, and they can't be updated because we haven't bumped the version numbers. Cheers, Simon