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