[commit: unix] master: change notes (1461d21)

Simon Marlow marlowsd at gmail.com
Mon Feb 11 09:52:41 CET 2013


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




More information about the Libraries mailing list