Proposal: packages in GHC should have different versions from hackage if the packages differ
igloo at earth.li
Fri Oct 26 14:02:37 CEST 2012
On Mon, Oct 15, 2012 at 04:48:20PM +0200, Henning Thielemann wrote:
> I try to compile a package with many dependencies using
> GHC-7.5.20120426 in order to check whether #5970 is resolved. This
> turns out to be difficult because this temporary GHC version seems
> to use packages with the same version as their counterparts on
> Hackage but different content.
> For example GHC-7.5.20120426 is bundled with unix-184.108.40.206 and
> bytestring-0.10.0.0. However the unix-220.127.116.11 on Hackage excludes
> bytestring-0.10.0.0. Thus cabal-install refuses to install something
> that depends on unix-18.104.22.168.
> Another example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled
> with base-22.214.171.124. However in GHC-7.5, Num is no longer superclass
> of Bits. I think such a change requires a version bump to base-4.6.
> In my opinion the condition should be that if you publish a package
> on Hackage then there should not be a package with the same version
> but different content somewhere else. Thus I propose that package
> versions are increased immediately in the repository according to
> the PVP if something is changed. That's how I handle versioning for
> my private packages, too.
And in the ticket Simon Marlow said:
> I definitely think we should change the policy - in fact I typically bump
> a library as soon as I change it, to avoid this problem. Is the policy
> written down anywhere? It wouldn't be hard to change, right?
The policy is not written down TTBOMK, and is easy to change.
However, one thing to bear in mind is upper-bound dependencies. Package
maintainers are unlikely to update their upper bounds to follow changes
in the development repos, so if we bump directory to 126.96.36.199 then cabal
will not be able to install any package that depends on
"directory < 1.3". While this can be manually worked around, it makes it
harder to investigate bug reports with the HEAD.
What exactly would the new policy be? Is it just the last component that
is bumped, or is the version number bumped according to the PvP? Is the
version bump relative to what was in the repo before, so after the
188.8.131.52 directory release we might have 184.108.40.206, 220.127.116.11 and 18.104.22.168 in
the repo before 22.214.171.124 is release, skipping 1.3 and 1.4? Or do you
check what the last release was and only bump if necessary relative to
that (so once the repo reaches 126.96.36.199 it will not be bumped further
until a release is made)?
Would we also follow this policy for packages we don't maintain (perhaps
with ghc-only version bumps if necessary)?
More information about the Libraries