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

Iavor Diatchki iavor.diatchki at
Fri Oct 26 16:11:09 CEST 2012


On Fri, Oct 26, 2012 at 5:02 AM, Ian Lynagh <igloo at> wrote:

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

I completely agree.

> 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
> directory release we might have, and in
> the repo before 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 it will not be bumped further
> until a release is made)?
What I usually do is to bump the version every time I want to depend on the
new library in another app (even if it is not released),
and simply skip release numbers.  I usually do the version increases
according to the PvP.

Would we also follow this policy for packages we don't maintain (perhaps
> with ghc-only version bumps if necessary)?
I think that it is a good idea to do this too, but it is probably better to
use a different versioning schema (e.g. something like package-1.1-ghc) ,
as these
versions are likely to be temporary, until the changes propagate upstream.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list