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