Proposal: packages in GHC should have different versions from hackage if the packages differ
lemming at henning-thielemann.de
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 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
> 18.104.22.168 directory release we might have 22.214.171.124, 126.96.36.199 and 188.8.131.52 in
> the repo before 184.108.40.206 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 220.127.116.11 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-18.104.22.168 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