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

Henning Thielemann lemming at
Fri Oct 26 16:37:18 CEST 2012

On Fri, 26 Oct 2012, Iavor Diatchki wrote:

> On Fri, Oct 26, 2012 at 5:02 AM, Ian Lynagh <igloo at> 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
> 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.

I would bump versions according to changes relative to the last released 
GHC version, otherwise you have to increase the versions too often.

E.g. if directory- was released with latest GHC and I make a change 
today that requires to bump to directory-1.2, and another change to the 
API tomorrow, then the version should still be directory-1.2 and not 
directory-1.3. That is, there are different packages with the same version 
flying around but a release of GHC should finally fix the API that is 
connected to a package version number.

More information about the Libraries mailing list