Proposal: packages in GHC should have different versions from hackage if the packages differ
Iavor Diatchki
iavor.diatchki at gmail.com
Fri Oct 26 16:11:09 CEST 2012
Hello,
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
> 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.
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.
-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121026/bd95e708/attachment.htm>
More information about the Libraries
mailing list