Re: [commit: unix] master: change notes (1461d21)
On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote:
On 03/02/13 20:48, Simon Marlow wrote:
On 02/02/13 14:11, Ian Lynagh wrote:
The unix version number is still 2.6.1.0, but doesn't the new policy http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages
mean that it should be bumped to 2.7.0.0 now?
Actually, having just tried to do this, I'm not sure how it's meant to work in practice. Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet; perhaps by the time it is released it will not work with the current Cabal/haskeline code. The other way is to make local ghc-only changes to relax the dependencies, but that would increase the risk that we'd release with a ghc branch of the library by mistake. Wouldn't it be better to go back to the previous scheme, where we didn't update version numbers until release time? Thanks Ian
On Fri, 8 Feb 2013, Ian Lynagh wrote:
On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote:
On 03/02/13 20:48, Simon Marlow wrote:
On 02/02/13 14:11, Ian Lynagh wrote:
The unix version number is still 2.6.1.0, but doesn't the new policy http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages
mean that it should be bumped to 2.7.0.0 now?
Actually, having just tried to do this, I'm not sure how it's meant to work in practice.
Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet;
Right, that's why you don't release the modified Cabal and haskeline packages to Hackage until a new release of GHC. Or if you do so, then you must bump the version of 'unix' again when you apply new modifications.
perhaps by the time it is released it will not work with the current Cabal/haskeline code.
The other way is to make local ghc-only changes to relax the dependencies, but that would increase the risk that we'd release with a ghc branch of the library by mistake.
Wouldn't it be better to go back to the previous scheme, where we didn't update version numbers until release time?
No, because with the old scheme there were two different versions of the same package with the same version number. That is, there was unix-2.6 on Hackage and unix-2.6 in a nightly build, but both archives had different content.
On Sat, Feb 09, 2013 at 12:20:22AM +0100, Henning Thielemann wrote:
On Fri, 8 Feb 2013, Ian Lynagh wrote:
On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote:
On 03/02/13 20:48, Simon Marlow wrote:
On 02/02/13 14:11, Ian Lynagh wrote:
The unix version number is still 2.6.1.0, but doesn't the new policy http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages
mean that it should be bumped to 2.7.0.0 now?
Actually, having just tried to do this, I'm not sure how it's meant to work in practice.
Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet;
Right, that's why you don't release the modified Cabal and haskeline packages to Hackage until a new release of GHC.
If upstream has applied a patch relaxing the bounds months before the GHC release, then there is a good chance it will end up in a release that gets uploaded to Hackage. Actually, I think that it's generally prefered that we only use released versions of libraries that have upstreams, in which case uploading it to hackage would be /encouraged/.
No, because with the old scheme there were two different versions of the same package with the same version number. That is, there was unix-2.6 on Hackage and unix-2.6 in a nightly build, but both archives had different content.
Nightly builds don't generally contain released versions of libraries. Even with the new version bumping scheme, 2 different nightly builds might have different code but the same version number. Thanks Ian
On Fri, 8 Feb 2013, Ian Lynagh wrote:
On Sat, Feb 09, 2013 at 12:20:22AM +0100, Henning Thielemann wrote:
No, because with the old scheme there were two different versions of the same package with the same version number. That is, there was unix-2.6 on Hackage and unix-2.6 in a nightly build, but both archives had different content.
Nightly builds don't generally contain released versions of libraries. Even with the new version bumping scheme, 2 different nightly builds might have different code but the same version number.
That's true. Thus I do not count nightly builds as releases and thus modifications to packages to not require version bumps between nightly builds.
On 08/02/13 23:05, Ian Lynagh wrote:
On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote:
On 03/02/13 20:48, Simon Marlow wrote:
On 02/02/13 14:11, Ian Lynagh wrote:
The unix version number is still 2.6.1.0, but doesn't the new policy http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages
mean that it should be bumped to 2.7.0.0 now?
Actually, having just tried to do this, I'm not sure how it's meant to work in practice.
Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet; perhaps by the time it is released it will not work with the current Cabal/haskeline code.
So a good solution to this would be to have two version bumps: one for development (2.7.x.x) and another bump for the final release (2.8.0.0). Then Cabal can make releases that relax the unix dependency to 2.7, which is fine because we'll never make a release of 2.7, it just keeps things working during development.
The other way is to make local ghc-only changes to relax the dependencies, but that would increase the risk that we'd release with a ghc branch of the library by mistake.
Wouldn't it be better to go back to the previous scheme, where we didn't update version numbers until release time?
There were serious problems with that scheme too, which is why we changed. We get into a situation where people can't test HEAD because some packages don't work with it, and they can't be updated because we haven't bumped the version numbers. Cheers, Simon
On Mon, Feb 11, 2013 at 08:52:41AM +0000, Simon Marlow wrote:
So a good solution to this would be to have two version bumps: one for development (2.7.x.x) and another bump for the final release (2.8.0.0). Then Cabal can make releases that relax the unix dependency to 2.7, which is fine because we'll never make a release of 2.7, it just keeps things working during development.
That sounded good, but while making the changes I realised that we are also not meant to eagerly update our copies of libraries, in case the latest versions aren't considered suitable for releasing with GHC. So perhaps we're better off just making ghc-only changes for the bumps for now, and sorting it out with upstream around release time. For now I've just made ghc-only changes, anyway. Thanks Ian
Hi, On 11/02/2013 08:52, Simon Marlow wrote:
So a good solution to this would be to have two version bumps: one for development (2.7.x.x) and another bump for the final release (2.8.0.0). Then Cabal can make releases that relax the unix dependency to 2.7, which is fine because we'll never make a release of 2.7, it just keeps things working during development.
What's the status of this proposal? As HTTP maintainer I'm strongly in favour of it for all libraries shipped with GHC including base, as it'd allow me to bump dependencies for development versions to keep the bleeding edge people happy, whilst still conforming to the PVP for stable versions. Cheers, Ganesh
Simon Marlow
On 08/02/13 23:05, Ian Lynagh wrote:
Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet; perhaps by the time it is released it will not work with the current Cabal/haskeline code.
So a good solution to this would be to have two version bumps: one for development (2.7.x.x) and another bump for the final release (2.8.0.0). Then Cabal can make releases that relax the unix dependency to 2.7, which is fine because we'll never make a release of 2.7, it just keeps things working during development.
This sounds like a nice way forward. Has there been any motion in this direction? Perhaps we could start with a library bump shortly after 7.8 is released? Cheers, - Ben
participants (5)
-
Ben Gamari -
Ganesh Sittampalam -
Henning Thielemann -
Ian Lynagh -
Simon Marlow