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

[Simon Marlow]

On 26/10/2012 13:02, Ian Lynagh wrote:

> 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)?

Bump versions according to the PVP, relative to the last version that 
was released on Hackage.  So for example that means that the first time 
we make an API-breaking change we bump the major number of the package, 
but no further bumps are needed until after the next release (which is 
typically when we next release GHC).

This means that the first API-breaking change to a package is a little 
painful because we have to go around and bump the dependencies on a few 
other packages, which might be maintained upstream, and that might 
require creating stable branches.  But this will have to be done 
sometime before the next GHC release anyway.

You can check whether the version has already been bumped by comparing 
it against the version in the previous GHC release.  It would be helpful 
to adopt a convention of adding a comment in the .cabal file indicating 
the GHC release corresponding to each package release version.

> Would we also follow this policy for packages we don't maintain (perhaps
> with ghc-only version bumps if necessary)?

We wouldn't be making API-breaking changes to packages we don't 
maintain, and we won't pull in API-breaking changes from upstream unless 
there has been a release.  If we need to modify an upstream package to 
bump its dependencies, then that will require a patchlevel version bump 
of the upstream package which we can hopefully push upstream first.

Cheers,
	Simon