Manuel Amador (Rudd-O) wrote:
1) No, I'm not on the committee.
2) The policy is similar.
3) Both approaches cannot work in parallel because the period is lexicographically distinct to the underscore
No.  Within a project you would have to choose, either the underscore form or the dot form within the 'release'.  You could not mix them.  And then either form would work just fine.

5) The policy has been tested and takes advantage of the already-deployed RPM code in tens of millions of machines out there. We do not know what sorts of malfunctions using underscores might cause.
Yes, and there are plenty of examples of packages that don't follow the policy as well.  Probably more than are actually following it.

4) The policy *does* make sense especially in the place you quoted it. The release begins with 0.1 and increments to 0.2 0.3 0.4 whenever you change the package (add patches, modify specfile) but continue to use the same source package, which is the purpose of the release tag in the first place -- to mark a new release of the SAME source package. Unfortunately, it requires that when a new beta source package (even one that is lexicographically later than the existing package) is compiled, the release must be bumped to upgrade it. My distutils packages explicitly punt this release bump to the packager so that he has control over which beta packages to push out. And the reason that the release tag always begins with 0. in nonstable releases is pretty dead simple: so that the release package with version 0.9.8-1 (the first official stable release) can be lexicographically higher and is automatically updated with package managers like yum.
The policy doesn't make sense in the example I quoted if you read the comments.   Look where it says upgrade to 0.9.2beta3 yet the example shows beta2.  
I can see that what is trying to be done is to add extra numerics just to make the numerics significant and then basically you can ignore the beta, alpha, etc.  But this is more confusing than helpful and its not necessary to make things lexically ordered.

The goal is proper lexical ordering so that rpm/yum is happy and packages will upgrade correctly.  And either form accomplishes this.


Guys, amirite?

> > Manuel,
> > Are you on the FPP committee? I looked at the fedora packaging
> > policy and it is rather similar except it has periods where we have
> > underscores. It would be nice if fedora could expand the policy to
> > allow the underscore style as well. Both approaches work just as
> > well. And to me the underscore form is a lot more readable.
> > Also, there isn't a lot of examples in the FPP regarding adding the
> > vcs revision number into the release string. I like the way we do it
> > because it's lexically correct always. Maybe this could be added to FPP?
> Manuel,
> Also examples in the fedora packaging policy don't even make sense.
> It's no wonder no one every gets this right.
> alsa-lib-0.9.2-0.1.beta1 (add a new patch on top of 0.9.2beta1)
> alsa-lib-0.9.2-0.2.beta1 (upgrade to 0.9.2beta2)
> alsa-lib-0.9.2-0.3.beta2 (upgrade to 0.9.2beta3)
> ^^^^^^^^^^^^^^^^^^And this ridiculous construction is from the
> Department of Redundancy Department
> This would be far better and make a lot more sense like:
> alsa-lib-0.9.2-0_beta1_00001727 # where 1727 is the vcs revision,
> using numbers like patch 1 is absolutely meanless to most people, they
> want to know what tagged release (beta1 tag) and then what revision
> contains the update patches.
> OR
> alsa-lib-0.9.2-0_beta1_p0 # where p0 means patch 0
> Regards,
> Gerry


Manuel Amador (Rudd-O) <> -
GPG key ID 0xC8D28B92 at

If you are what you eat, does that mean Euell Gibbons really was a nut?