Hackage policy question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

John Meacham
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⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12