Hackage policy question

Iavor Diatchki

8 Sep 2008 8 Sep '08

7:26 p.m.

Hi, I just noticed that hackage has introduced a new policy to disallow changes to a package without bumping the version. I understand that this is probably a good idea for changes to the source code, but it really would be nice to have a backdoor that allows for other changes. For example, I just uploaded a package, and realized that I forgot to add a home-page entry in the cabal file. I do not plan to increase the version number of my application, only so that I can upload a new version (the source code has not changed after all!). I can imagine similar problems related to fixing typos in the description, and other fixes to the meta-data. So, could we please revert to the old policy? (if we really want to be fancy, the hackage upload script could check that the source code, and other fields, such as LICENSE have not changed, as these should really bump the version... in the mean time though, I think just being responsible members of the community would work just as well!). -Iavor

Show replies by date

Duncan Coutts

9 Sep 9 Sep

6:59 p.m.

On Mon, 2008-09-08 at 16:26 -0700, Iavor Diatchki wrote:

...

Hi, I just noticed that hackage has introduced a new policy to disallow changes to a package without bumping the version. I understand that this is probably a good idea for changes to the source code, but it really would be nice to have a backdoor that allows for other changes. For example, I just uploaded a package, and realized that I forgot to add a home-page entry in the cabal file. I do not plan to increase the version number of my application, only so that I can upload a new version (the source code has not changed after all!). I can imagine similar problems related to fixing typos in the description, and other fixes to the meta-data.

Yes. We've thought about this a bit. I'll tell you how I think it should be managed, though I accept not everyone agrees with me. The .tar.gz packages are pristine and must not change, however the .cabal file that is kept in the hackage index could change and that information will be reflected both in the hackage website and just as importantly for tools like cabal-install. So not only could the maintainer fix urls or whatever but also adjust dependencies in the light of test results. Consider the analogy to pristine tarballs and debian or gentoo meta-data files. The former never changes for a particular version, but the meta-data can be adjusted as the distributors see fit. The difference here is that those two would be in the same format, the .cabal file inside the tarball that never changes and the one in the index which may do. This is also the objection that some people have, that it would be confusing to have the two versions, especially that unpacking the tarball gives the old unmodified version.

...

So, could we please revert to the old policy?

No :-) But I hope with the above system that will not be necessary. I hope to implement this feature in the new hackage server implementation that I'll be announcing shortly. Really it's essential that the md5sums of tarballs never change. Untold chaos results if they are allowed to change. For one thing our urls become unusable for distro systems like gentoo, fedora etc and they would have to take snapshots and keep their own pristine mirrors rather than using our url as the canonical reference (obviously they do their own mirroring too but they usually refer back to a canonical source). That would be a huge pain for them and a barrier to our acceptance into distros.

...

(if we really want to be fancy, the hackage upload script could check that the source code, and other fields, such as LICENSE have not changed, as these should really bump the version... in the mean time though, I think just being responsible members of the community would work just as well!).

Indeed we'll also have to check things carefully if we allow package or distribution maintainers to adjust the .cabal files in the index. For example changing exposed modules or the name or version number is right out. We'll err on the restrictive side and gradually loosen as we decide it's safe and acceptable. Duncan

Wolfgang Jeltsch

10 Sep 10 Sep

4:11 a.m.

Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:

...

[…]

...

The .tar.gz packages are pristine and must not change, however the .cabal file that is kept in the hackage index could change and that information will be reflected both in the hackage website and just as importantly for tools like cabal-install.

I don’t think this is a good idea. The package description, list of exposed modules, etc. belongs to the software, in my opinion. So changing it means changing the software which should be reflected by a version number increase. Why can’t package maintainers double-check that they got everything in the Cabal file right before the package is uploaded to Hackage? And if one has forgotten a URL or something like that, it is still possible to release a new version where just the 4th component of the version number was changed which means precisely that the interface didn’t change.

...

[…]

...

The difference here is that those two would be in the same format, the .cabal file inside the tarball that never changes and the one in the index which may do. This is also the objection that some people have, that it would be confusing to have the two versions, especially that unpacking the tarball gives the old unmodified version.

Yes, it *is* confusing.

...

[…]

...

I hope to implement this feature in the new hackage server implementation that I'll be announcing shortly.

May I kindly ask you to *not* implement this feature?

...

[…]

Best wishes, Wolfgang

Duncan Coutts

5:47 a.m.

On Wed, 2008-09-10 at 10:11 +0200, Wolfgang Jeltsch wrote:

...

Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:

...
[…]

...
The .tar.gz packages are pristine and must not change, however the .cabal file that is kept in the hackage index could change and that information will be reflected both in the hackage website and just as importantly for tools like cabal-install.

I don’t think this is a good idea. The package description, list of exposed modules, etc. belongs to the software, in my opinion. So changing it means changing the software which should be reflected by a version number increase.

Remember that all the distributors are doing this all the time and it doesn't cause (many) problems. They change the meta-data from what the upstream authors give and they add patches etc etc. Granted, they do use a revision number to track this normally. For example a package foo-1.0 on hackage would become dev-haskell/foo-1.0.ebuild in gentoo and if it needs to be updated for some reason it becomes dev-haskell/foo-1.0-r1.ebuild and the number is increased by one for every subsequent revision. Distros like debian have similar systems.

...

Why can’t package maintainers double-check that they got everything in the Cabal file right before the package is uploaded to Hackage? And if one has forgotten a URL or something like that, it is still possible to release a new version where just the 4th component of the version number was changed which means precisely that the interface didn’t change.

Note that the distros are actually making code changes (applying bug fix patches) and not bumping the upstream version number, though they do bump their additional revision number. I'm not suggesting anything so radical. I'm just suggesting that you could change the category tags, or improve the description. The most radical thing is tightening or relaxing the version constraints on dependencies. For example if your package depends on foo >= 1.0 && < 1.1 but then foo-1.1 comes out and although it does contain api changes and had the potential to break your package (which is why you put the conservative upper bound) it turns out that you were not using the bits of the api that changed and it does in fact work with 1.1 so you can adjust the dependencies to foo >= 1.0 && < 1.2. Again, this is just the sort of thing that distros do.

...

...
[…]

...
The difference here is that those two would be in the same format, the .cabal file inside the tarball that never changes and the one in the index which may do. This is also the objection that some people have, that it would be confusing to have the two versions, especially that unpacking the tarball gives the old unmodified version.

Yes, it *is* confusing.

...
[…]

...
I hope to implement this feature in the new hackage server implementation that I'll be announcing shortly.

May I kindly ask you to *not* implement this feature?

Well we need something like it I think. At least if we want to be able to install things direct from hackage and have some level of reliance on stated dependencies reflecting reality. It also allows us to share some QA between all the distros which have to do this work anyway. If we consider hackage as a raw upstream package collection that gets picked over and QA'd by the distros then it's not necessary. But I think we want to use it for both, for pristine upstream tarball releases but also I think we expect to be able to use it directly with things like cabal-install and so adding some distro-like management features is useful. So we should think about how to make it less confusing. Perhaps like distributors use an extra revision number we should do the same. I had hoped that would not be necessary but that's probably not realistic. Duncan

Ketil Malde

6:09 a.m.

Duncan Coutts writes:

...

So we should think about how to make it less confusing. Perhaps like distributors use an extra revision number we should do the same. I had hoped that would not be necessary but that's probably not realistic.

If we go this route, it'd be nice to have a distinguishable syntax, like Gentoo's .rN, so that we don't have to remember whether it's digit four or five that signifies "administrative" changes. -k -- If I haven't seen further, it is by standing in the footprints of giants

Duncan Coutts

6:40 a.m.

On Wed, 2008-09-10 at 12:09 +0200, Ketil Malde wrote:

...

Duncan Coutts writes:

...
So we should think about how to make it less confusing. Perhaps like distributors use an extra revision number we should do the same. I had hoped that would not be necessary but that's probably not realistic.

If we go this route, it'd be nice to have a distinguishable syntax, like Gentoo's .rN, so that we don't have to remember whether it's digit four or five that signifies "administrative" changes.

Yes, it must be distinguished because we cannot constrain the upstream maintainers version policy. We do not know and should not care how many version places they use. Duncan

Wolfgang Jeltsch

6:48 a.m.

Am Mittwoch, 10. September 2008 11:47 schrieben Sie:

...

On Wed, 2008-09-10 at 10:11 +0200, Wolfgang Jeltsch wrote:

...
Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:

...
[…]

The .tar.gz packages are pristine and must not change, however the .cabal file that is kept in the hackage index could change and that information will be reflected both in the hackage website and just as importantly for tools like cabal-install.

I don’t think this is a good idea. The package description, list of exposed modules, etc. belongs to the software, in my opinion. So changing it means changing the software which should be reflected by a version number increase.

Remember that all the distributors are doing this all the time and it doesn't cause (many) problems. They change the meta-data from what the upstream authors give and they add patches etc etc.

Granted, they do use a revision number to track this normally.

And this is an important difference, in my opinion. Changing meta-data is probably okay if a revision number is changed.

...

[…]

...

The most radical thing is tightening or relaxing the version constraints on dependencies. For example if your package depends on foo >= 1.0 && < 1.1 but then foo-1.1 comes out and although it does contain api changes and had the potential to break your package (which is why you put the conservative upper bound) it turns out that you were not using the bits of the api that changed and it does in fact work with 1.1 so you can adjust the dependencies to foo

...
= 1.0 && < 1.2.

But what happens if you need the loose dependencies. cabal-install checks the updated Cabal file and might see that you’ve already installed the correct dependencies. It downloads and unpacks the package and then Cabal uses the Cabal file included in the package and complains about unmet dependencies. Or shall there be a mechanism to overwrite the package’s Cabal file with the updated Cabal file?

...

[…]

...

So we should think about how to make it less confusing. Perhaps like distributors use an extra revision number we should do the same.

Yes, maybe this is the way to go.

...

[…]

Best wishes, Wolfgang

Brandon S. Allbery KF8NH

11:49 a.m.

On 2008 Sep 10, at 6:48, Wolfgang Jeltsch wrote:

...

Am Mittwoch, 10. September 2008 11:47 schrieben Sie:

...
So we should think about how to make it less confusing. Perhaps like distributors use an extra revision number we should do the same.

Yes, maybe this is the way to go.

Everyone who manages packages runs into this, and all of them use revision numbers like this. (.rN for gentoo was already mentioned; BSD ports and MacPorts use _, RPM uses -. Depot collections at CMU also use -.) And while we're on that topic, most of them also have an "epoch" which overrides the version number. If for some reason an updated package *doesn't* change the version, or goes backwards (because of a major bug leading to backing off the new release), you increase the epoch so dependent packages don't get confused when it's re-released. If we're considering modifying hackage's versioning, we should probably decide if we want/need this now instead of having to add it in later when something major goes *boom*. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Duncan Coutts

5:51 p.m.

On Wed, 2008-09-10 at 11:49 -0400, Brandon S. Allbery KF8NH wrote:

...

On 2008 Sep 10, at 6:48, Wolfgang Jeltsch wrote:

...
Am Mittwoch, 10. September 2008 11:47 schrieben Sie:

...
So we should think about how to make it less confusing. Perhaps like distributors use an extra revision number we should do the same.

Yes, maybe this is the way to go.

Everyone who manages packages runs into this, and all of them use revision numbers like this. (.rN for gentoo was already mentioned; BSD ports and MacPorts use _, RPM uses -. Depot collections at CMU also use -.)

And while we're on that topic, most of them also have an "epoch" which overrides the version number. If for some reason an updated package *doesn't* change the version, or goes backwards (because of a major bug leading to backing off the new release), you increase the epoch so dependent packages don't get confused when it's re-released. If we're considering modifying hackage's versioning, we should probably decide if we want/need this now instead of having to add it in later when something major goes *boom*.

We've thought about this and we think we do not need epoch numbers since we're in the lucky position of doing the upstream versioning. http://hackage.haskell.org/trac/hackage/ticket/135 Hmm, I think the discussion on that ticket must have been in an email thread in cabal-devel. Duncan

Brandon S. Allbery KF8NH

6:35 p.m.

On 2008 Sep 10, at 17:51, Duncan Coutts wrote:

...

...
dependent packages don't get confused when it's re-released. If we're considering modifying hackage's versioning, we should probably decide if we want/need this now instead of having to add it in later when something major goes *boom*.

We've thought about this and we think we do not need epoch numbers since we're in the lucky position of doing the upstream versioning.

Are we? I think the package author has final say if a package needs to be backed off, and any packages released between the rollback and the next release with dependencies on the backed-off package will be problematic, no matter how draconian hackage's version checking is. (This is a different situation from datecode versions as in the trac ticket.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Duncan Coutts

6:43 p.m.

On Wed, 2008-09-10 at 18:35 -0400, Brandon S. Allbery KF8NH wrote:

...

On 2008 Sep 10, at 17:51, Duncan Coutts wrote:

...
...
dependent packages don't get confused when it's re-released. If we're considering modifying hackage's versioning, we should probably decide if we want/need this now instead of having to add it in later when something major goes *boom*.

We've thought about this and we think we do not need epoch numbers since we're in the lucky position of doing the upstream versioning.

Are we? I think the package author has final say if a package needs to be backed off, and any packages released between the rollback and the next release with dependencies on the backed-off package will be problematic, no matter how draconian hackage's version checking is. (This is a different situation from datecode versions as in the trac ticket.)

I'm not quite sure I follow. Certainly it's the author/maintainer who decides the version number. It's up to them to pick it, but they know the ordering of version numbers. As I understand it, epochs were mainly introduced to cope with un-cooperative upstream maintainers whereas here maintainers already have to specify a version number in the Cabal/Hackage scheme and there's no way for them to pretend or unilaterally declare that 3 < 2 or any other such silliness. To account for having experimental versions available at the same time as stable versions we're planning to let maintainers add a suggested/soft version constraint. Is that related to what you mean by "backing off" and "rollback"? Duncan

Brandon S. Allbery KF8NH

6:53 p.m.

On 2008 Sep 10, at 18:43, Duncan Coutts wrote:

...

On Wed, 2008-09-10 at 18:35 -0400, Brandon S. Allbery KF8NH wrote:

...
On 2008 Sep 10, at 17:51, Duncan Coutts wrote:

...
...
dependent packages don't get confused when it's re-released. If we're considering modifying hackage's versioning, we should probably decide if we want/need this now instead of having to add it in later when something major goes *boom*.

We've thought about this and we think we do not need epoch numbers since we're in the lucky position of doing the upstream versioning.

Are we? I think the package author has final say if a package needs to be backed off, and any packages released between the rollback and the next release with dependencies on the backed-off package will be problematic, no matter how draconian hackage's version checking is. (This is a different situation from datecode versions as in the trac ticket.)

I'm not quite sure I follow. Certainly it's the author/maintainer who decides the version number. It's up to them to pick it, but they know the ordering of version numbers.

As I understand it, epochs were mainly introduced to cope with un-cooperative upstream maintainers whereas here maintainers already have to specify a version number in the Cabal/Hackage scheme and there's

That is one use. The far more common use, at least in FreeBSD ports, is when a version of a port has to be backed off; if any subsequently released packages depend on the backed-off version, things get nasty when the port is re-updated later. This may not involve the port author; it could be an unexpected interaction with an updated dependency under certain circumstances. "Backed off", in the FreebSD context, means an older version of the port is restored from CVS; in the context of Hackage it means removing the broken version and making the previous version the current version. Basically, you *do* have control over this... but it's possible for the effects to propagate rather widely before such an interaction is discovered, resulting in needing to revise either many packages to reflect the corrected dependency... or updating one epoch. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Duncan Coutts

7:24 p.m.

On Wed, 2008-09-10 at 18:53 -0400, Brandon S. Allbery KF8NH wrote:

...

...
As I understand it, epochs were mainly introduced to cope with un-cooperative upstream maintainers whereas here maintainers already have to specify a version number in the Cabal/Hackage scheme and there's

That is one use. The far more common use, at least in FreeBSD ports, is when a version of a port has to be backed off; if any subsequently released packages depend on the backed-off version, things get nasty when the port is re-updated later. This may not involve the port author; it could be an unexpected interaction with an updated dependency under certain circumstances.

"Backed off", in the FreebSD context, means an older version of the port is restored from CVS; in the context of Hackage it means removing the broken version and making the previous version the current version.

Ok, so we never remove packages. So that's ok. You could fix the above problem in two ways, adjust the suggested version constraint (which is of course still vapourware) or upload a new version. (Well, we sometimes remove packages that were uploaded without the consent of the author. But that does not apply here.) Duncan

Ross Paterson

5:26 a.m.

On Tue, Sep 09, 2008 at 10:59:17PM +0000, Duncan Coutts wrote:

...

The .tar.gz packages are pristine and must not change, however the .cabal file that is kept in the hackage index could change and that information will be reflected both in the hackage website and just as importantly for tools like cabal-install. So not only could the maintainer fix urls or whatever but also adjust dependencies in the light of test results. Consider the analogy to pristine tarballs and debian or gentoo meta-data files. The former never changes for a particular version, but the meta-data can be adjusted as the distributors see fit.

So if Debian or Gentoo etc repackage one of these packages in their distributions, what is the pristine tarball that they use?

Duncan Coutts

6:07 a.m.

On Wed, 2008-09-10 at 10:26 +0100, Ross Paterson wrote:

...

On Tue, Sep 09, 2008 at 10:59:17PM +0000, Duncan Coutts wrote:

...
The .tar.gz packages are pristine and must not change, however the .cabal file that is kept in the hackage index could change and that information will be reflected both in the hackage website and just as importantly for tools like cabal-install. So not only could the maintainer fix urls or whatever but also adjust dependencies in the light of test results. Consider the analogy to pristine tarballs and debian or gentoo meta-data files. The former never changes for a particular version, but the meta-data can be adjusted as the distributors see fit.

So if Debian or Gentoo etc repackage one of these packages in their distributions, what is the pristine tarball that they use?

They use the one and only pristine tarball. As for what meta-data they choose, that's up to them, they have the choice of using the original .cabal file in the .tar.gz or taking advantage of the updated version. Duncan

Ross Paterson

7:42 p.m.

On Wed, Sep 10, 2008 at 10:07:54AM +0000, Duncan Coutts wrote:

...

On Wed, 2008-09-10 at 10:26 +0100, Ross Paterson wrote:

...
So if Debian or Gentoo etc repackage one of these packages in their distributions, what is the pristine tarball that they use?

They use the one and only pristine tarball. As for what meta-data they choose, that's up to them, they have the choice of using the original .cabal file in the .tar.gz or taking advantage of the updated version.

Since the modified version may contain essential fixes, they'll almost certainly want that. And they'll want to keep their mods separate, so the updated .cabal file becomes another part of the upstream source, with secondary versioning. To which they add a third level of versioning for their distro packaging. And all this versioning is real; it's keeping track of significant changes at each stage. And then there's the psychological effect. Make it easier to clean up broken releases afterwards, and you'll have more of them.

John Meacham

19 Nov 19 Nov

11:25 p.m.

The usual solution to this is the 'release version', which is used in most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the release version which documents what version the meta-info is. For instance, when bugs are fixed in the rpm spec file or deb package that number is bumped and it is independent of the underlying packaged softwares release. It would be very useful if hackage could support something like this. John -- John Meacham - ⑆repetae.net⑆john⑈

Austin Seipp

20 Nov 20 Nov

1:15 a.m.

...

The usual solution to this is the 'release version', which is used in most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the release version which documents what version the meta-info is. For instance, when bugs are fixed in the rpm spec file or deb package that number is bumped and it is independent of the underlying packaged softwares release. It would be very useful if hackage could support something like this.

John

Hi John, Hackage currently does not support this policy because of e.g. dependency tracking - previously hackage *was* allowed to upload packages of the form 'foo-1.2.3-unstable' but the problem was that it includes the -unstable as part of the version number. In the general case - arbitrary identifier suffixes as part of the version - when someone just specifies a dependency on 'foo', does foo-1.0-bar > foo-1.0-baz or not? Duncan 'fixed' hackage and put the restriction on the upload form - at the time I discussed this with him due to a problem with hsgnutls because it had the -barracuda suffix on the package version. In the case of meta-info specifying doc versions, I think we could allow package names of the form 'x.y.z_n' where x y z and n can only be integers. Then statements of the form e.g. 'foo-2.0_4 > foo-2.0_3' make sense and cabal and cabal install can understand this - of course, ghc-pkg won't accept such a version identifier, so it will only have meaning to cabal but in the case of documentation fixes and the like that's not much of a big deal really. Austin

Duncan Coutts

5:52 a.m.

On Wed, 2008-11-19 at 20:25 -0800, John Meacham wrote:

...

The usual solution to this is the 'release version', which is used in most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the release version which documents what version the meta-info is. For instance, when bugs are fixed in the rpm spec file or deb package that number is bumped and it is independent of the underlying packaged softwares release. It would be very useful if hackage could support something like this.

There are two solutions to this, one is to say it's just a convention, eg using 1.2.4 when you give it your meaning of 1.2_4. The reason deb, rpm etc need to distinguish the extra version is precisely because they do not control the upstream version number. Of course in the case of package authors uploading packages to hackage that is not the case. It's an upstream packaging format, not a downstream one. However when we want to manage a collection of packages on hackage then it is a bit more like a downstream distro and in that case there is a stronger argument for making tweaks to meta-data (without uploading new tarballs) and recording those revision numbers. Eg relaxing or tightening versions of constraints as new information becomes available. One possibility there is to keep a version of the .cabal file outside of the tarball in the hackage index and record a x-hackage-revision: 3 field in that. It'd be incremented each time someone (author/maintainer or packager collection herder) makes a tweak. Duncan

John Meacham

7:06 a.m.

Well, my main concern is that I have projects that have several distribution formats, tarball, rpm, deb, and hopefully hackage (alongside the others as equals). I don't want the version numbers to get out of sync though, just because I have to reroll the hackage, or rpm, or whatever release, I don't want to have to artificially increase its version number such that it gets out of sync with the actual version number of the package. For instance, I have a yum repository that contains my various projects (DrIFT, jhc, etc..) and bumping the release version is what I need to do to get 'yum update' to grab new versions, but I don't want to have to rerelease hackage, tarball, or deb versions to keep my version numbers in sync just for fixing an rpm or distribution compatability issue. With rpm I don't have to do this since it has a release version, so I am looking for something similar on the hackage side of things. John -- John Meacham - ⑆repetae.net⑆john⑈

Duncan Coutts

7:56 a.m.

On Thu, 2008-11-20 at 04:06 -0800, John Meacham wrote:

...

Well, my main concern is that I have projects that have several distribution formats, tarball, rpm, deb, and hopefully hackage (alongside the others as equals). I don't want the version numbers to get out of sync though, just because I have to reroll the hackage, or rpm, or whatever release, I don't want to have to artificially increase its version number such that it gets out of sync with the actual version number of the package. For instance, I have a yum repository that contains my various projects (DrIFT, jhc, etc..) and bumping the release version is what I need to do to get 'yum update' to grab new versions, but I don't want to have to rerelease hackage, tarball, or deb versions to keep my version numbers in sync just for fixing an rpm or distribution compatability issue. With rpm I don't have to do this since it has a release version, so I am looking for something similar on the hackage side of things.

If it's purely a change in the .cabal file then the second mechanism that I described should be ok. Or release foo-x.y.z.1 only on hackage with the semantics being that it's a minor build fix for the primary version number foo-x.y.z. The only difference is that someone can install both variants simultaneously. Duncan

John Meacham

8:56 a.m.

On Thu, Nov 20, 2008 at 12:56:31PM +0000, Duncan Coutts wrote:

...

On Thu, 2008-11-20 at 04:06 -0800, John Meacham wrote:

...
Well, my main concern is that I have projects that have several distribution formats, tarball, rpm, deb, and hopefully hackage (alongside the others as equals). I don't want the version numbers to get out of sync though, just because I have to reroll the hackage, or rpm, or whatever release, I don't want to have to artificially increase its version number such that it gets out of sync with the actual version number of the package. For instance, I have a yum repository that contains my various projects (DrIFT, jhc, etc..) and bumping the release version is what I need to do to get 'yum update' to grab new versions, but I don't want to have to rerelease hackage, tarball, or deb versions to keep my version numbers in sync just for fixing an rpm or distribution compatability issue. With rpm I don't have to do this since it has a release version, so I am looking for something similar on the hackage side of things.

If it's purely a change in the .cabal file then the second mechanism that I described should be ok.

Or release foo-x.y.z.1 only on hackage with the semantics being that it's a minor build fix for the primary version number foo-x.y.z. The only difference is that someone can install both variants simultaneously.

yeah, but then we have the odd case of things like frisby 0.9.0 and 0.9.0.1 both floating about, where the second is actually just the cabalized version of the first, and not an actual version. it gets even more complicated if I actually want to create a _real_ frisby 0.9.0.1 for a bug fix in the code. A dedicated 'release' number would be ideal and would make things more in line with the other packaging formats. John -- John Meacham - ⑆repetae.net⑆john⑈

Duncan Coutts

1:48 p.m.

On Thu, 2008-11-20 at 05:56 -0800, John Meacham wrote:

...

On Thu, Nov 20, 2008 at 12:56:31PM +0000, Duncan Coutts wrote:

...
On Thu, 2008-11-20 at 04:06 -0800, John Meacham wrote:

...
Well, my main concern is that I have projects that have several distribution formats, tarball, rpm, deb, and hopefully hackage (alongside the others as equals). I don't want the version numbers to get out of sync though, just because I have to reroll the hackage, or rpm, or whatever release, I don't want to have to artificially increase its version number such that it gets out of sync with the actual version number of the package. For instance, I have a yum repository that contains my various projects (DrIFT, jhc, etc..) and bumping the release version is what I need to do to get 'yum update' to grab new versions, but I don't want to have to rerelease hackage, tarball, or deb versions to keep my version numbers in sync just for fixing an rpm or distribution compatability issue. With rpm I don't have to do this since it has a release version, so I am looking for something similar on the hackage side of things.

If it's purely a change in the .cabal file then the second mechanism that I described should be ok.

Or release foo-x.y.z.1 only on hackage with the semantics being that it's a minor build fix for the primary version number foo-x.y.z. The only difference is that someone can install both variants simultaneously.

yeah, but then we have the odd case of things like frisby 0.9.0 and 0.9.0.1 both floating about, where the second is actually just the cabalized version of the first, and not an actual version. it gets even more complicated if I actually want to create a _real_ frisby 0.9.0.1 for a bug fix in the code. A dedicated 'release' number would be ideal and would make things more in line with the other packaging formats.

What would it mean? Is frisby-0.9.0-r1 different from frisby-0.9.0? Can I install both at once? Is it just a tag on one digit of the version number or does it change the semantics? Can another package depend on frisby >= 0.9.0-r3 ? Duncan

John Meacham

5 p.m.

On Thu, Nov 20, 2008 at 06:48:47PM +0000, Duncan Coutts wrote:

...

...
yeah, but then we have the odd case of things like frisby 0.9.0 and 0.9.0.1 both floating about, where the second is actually just the cabalized version of the first, and not an actual version. it gets even more complicated if I actually want to create a _real_ frisby 0.9.0.1 for a bug fix in the code. A dedicated 'release' number would be ideal and would make things more in line with the other packaging formats.

What would it mean? Is frisby-0.9.0-r1 different from frisby-0.9.0? Can I install both at once? Is it just a tag on one digit of the version number or does it change the semantics? Can another package depend on frisby >= 0.9.0-r3 ?

No, the idea of a release number is that it does not take place in dependency tracking. frisby-0.9.0 is the base package, independent of hackage,rpm, or any distro that defines the API and is what you depend on in code. the release specifies the current 'roll' or 'build', a specific set of options and commands to get it to build in a certain environment. frisby-0.9.0-r4 always superceeds and should replace frisby-0.9.0-r3, but as far as anything is concerned frisby-0.9.0 is all that is installed. Another motivating situation is that I generally don't maintain the cabalized (or debed for that matter) builds of my tools but they are done by third parties, so when they need to upload a fixed version to hackage, it would give them a place to bump up the release number without having to coordinate anything upstream. It says "this is a new hackaged version of the same project". John -- John Meacham - ⑆repetae.net⑆john⑈

6026

Age (days ago)

6099

Last active (days ago)

List overview

Download

23 comments

8 participants

participants (8)

Austin Seipp
Brandon S. Allbery KF8NH
Duncan Coutts
Iavor Diatchki
John Meacham
Ketil Malde
Ross Paterson
Wolfgang Jeltsch