Proposal: packages in GHC should have different versions from hackage if the packages differ

[Ian Lynagh]

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-2.5.1.0 and
> bytestring-0.10.0.0. However the unix-2.5.1.0 on Hackage excludes
> bytestring-0.10.0.0. Thus cabal-install refuses to install something
> that depends on unix-2.5.1.0.
>  Another example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled
> with base-4.5.0.0. 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 1.3.0.0 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
1.2.0.1 directory release we might have 1.3.0.0, 1.4.0.0 and 1.5.0.0 in
the repo before 1.5.0.0 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 1.3.0.0 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)?


Thanks
Ian