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

older
Time to add the Traversable laws...

Henning Thielemann

15 Oct 2012 15 Oct '12

10:48 a.m.

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@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.

Show replies by date

Johan Tibell

15 Oct 15 Oct

11:09 a.m.

New subject: 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 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 26 Oct

8:02 a.m.

New subject: 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. However, one thing to bear in mind is upper-bound dependencies. Package maintainers are unlikely to update their upper bounds to follow changes in the development repos, so if we bump directory to 1.3.0.0 then cabal will not be able to install any package that depends on "directory < 1.3". While this can be manually worked around, it makes it harder to investigate bug reports with the HEAD. 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)? Would we also follow this policy for packages we don't maintain (perhaps with ghc-only version bumps if necessary)? Thanks Ian

Iavor Diatchki

10:11 a.m.

New subject: 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 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

Henning Thielemann

10:37 a.m.

New subject: 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 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.

Simon Marlow

31 Oct 31 Oct

8:22 a.m.

New subject: 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

4585

Age (days ago)

4601

Last active (days ago)

List overview

Download

5 comments

5 participants

participants (5)

Henning Thielemann
Ian Lynagh
Iavor Diatchki
Johan Tibell
Simon Marlow