[commit: unix] master: change notes (1461d21)
Ian Lynagh
ian at well-typed.com
Sat Feb 9 00:30:48 CET 2013
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
More information about the Libraries
mailing list