Proposal: packages in GHC should have different versions from hackage if the packages differ
iavor.diatchki at gmail.com
Fri Oct 26 16:11:09 CEST 2012
On Fri, Oct 26, 2012 at 5:02 AM, Ian Lynagh <igloo at earth.li> 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
> 184.108.40.206 directory release we might have 220.127.116.11, 18.104.22.168 and 22.214.171.124 in
> the repo before 126.96.36.199 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 188.8.131.52 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) ,
versions are likely to be temporary, until the changes propagate upstream.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries