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

[Henning Thielemann]

On Fri, 26 Oct 2012, Iavor Diatchki wrote:

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