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