[Haskell-cafe] Hackage policy question

[John Meacham]

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⑈