Henning Thielemann | 15 Oct 16:48 2012
Picon

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


I opened the following ticket [1] about the versioning of packages shipped 
with GHC, but was told to start a discussion first. I hope 
libraries <at> haskell.org is the right place to do that.

[1] http://hackage.haskell.org/trac/ghc/ticket/6053

Let me repeat the issue description here:

I try to compile a package with many dependencies using GHC-7.5.20120426 
in order to check whether #5970 is resolved. This turns out to be 
difficult because this temporary GHC version seems to use packages with 
the same version as their counterparts on Hackage but different content.
  For example GHC-7.5.20120426 is bundled with unix-2.5.1.0 and 
bytestring-0.10.0.0. However the unix-2.5.1.0 on Hackage excludes 
bytestring-0.10.0.0. Thus cabal-install refuses to install something that 
depends on unix-2.5.1.0.
  Another example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled with 
base-4.5.0.0. However in GHC-7.5, Num is no longer superclass of Bits. I 
think such a change requires a version bump to base-4.6.

In my opinion the condition should be that if you publish a package on 
Hackage then there should not be a package with the same version but 
different content somewhere else. Thus I propose that package versions are 
increased immediately in the repository according to the PVP if something 
is changed. That's how I handle versioning for my private packages, too.
Johan Tibell | 15 Oct 17:09 2012
Picon

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

On Mon, Oct 15, 2012 at 7:48 AM, Henning Thielemann
<lemming <at> henning-thielemann.de> wrote:
> In my opinion the condition should be that if you publish a package on
> Hackage then there should not be a package with the same version but
> different content somewhere else. Thus I propose that package versions are
> increased immediately in the repository according to the PVP if something is
> changed. That's how I handle versioning for my private packages, too.

Sounds reasonable. This is a GHC internal matter in my opinion, as
they're not releasing these libraries under the non-working version
numbers.
Ian Lynagh | 26 Oct 14:02 2012
Picon

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

On Mon, Oct 15, 2012 at 04:48:20PM +0200, Henning Thielemann wrote:
> 
> I try to compile a package with many dependencies using
> GHC-7.5.20120426 in order to check whether #5970 is resolved. This
> turns out to be difficult because this temporary GHC version seems
> to use packages with the same version as their counterparts on
> Hackage but different content.
>  For example GHC-7.5.20120426 is bundled with unix-2.5.1.0 and
> bytestring-0.10.0.0. However the unix-2.5.1.0 on Hackage excludes
> bytestring-0.10.0.0. Thus cabal-install refuses to install something
> that depends on unix-2.5.1.0.
>  Another example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled
> with base-4.5.0.0. However in GHC-7.5, Num is no longer superclass
> of Bits. I think such a change requires a version bump to base-4.6.
> 
> In my opinion the condition should be that if you publish a package
> on Hackage then there should not be a package with the same version
> but different content somewhere else. Thus I propose that package
> versions are increased immediately in the repository according to
> the PVP if something is changed. That's how I handle versioning for
> my private packages, too.

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?

The policy is not written down TTBOMK, and is easy to change.

(Continue reading)

Iavor Diatchki | 26 Oct 16:11 2012
Picon

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

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



 
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 26 Oct 16:37 2012
Picon

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


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.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Simon Marlow | 31 Oct 13:22 2012
Picon

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

On 26/10/2012 13:02, Ian Lynagh 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)?

Bump versions according to the PVP, relative to the last version that 
was released on Hackage.  So for example that means that the first time 
we make an API-breaking change we bump the major number of the package, 
but no further bumps are needed until after the next release (which is 
typically when we next release GHC).

This means that the first API-breaking change to a package is a little 
painful because we have to go around and bump the dependencies on a few 
other packages, which might be maintained upstream, and that might 
require creating stable branches.  But this will have to be done 
sometime before the next GHC release anyway.

You can check whether the version has already been bumped by comparing 
it against the version in the previous GHC release.  It would be helpful 
to adopt a convention of adding a comment in the .cabal file indicating 
the GHC release corresponding to each package release version.

> Would we also follow this policy for packages we don't maintain (perhaps
> with ghc-only version bumps if necessary)?

We wouldn't be making API-breaking changes to packages we don't 
maintain, and we won't pull in API-breaking changes from upstream unless 
there has been a release.  If we need to modify an upstream package to 
bump its dependencies, then that will require a patchlevel version bump 
of the upstream package which we can hopefully push upstream first.

Cheers,
	Simon

Gmane