On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
>>C-3. Non-Numeric Version to Release
>>-----------------------------------
>>As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
>>versioned packages can be problematic so they must be treated with care.
>> These are cases where the upstream version has letters rather than
>>simple numbers in their version. Often they have tags like alpha, beta,
>>rc, or letters like a and b denoting that it is a version before or
>>after the number. Read section B to understand why we cannot simply put
>>these letters into the version tag.
>>
>>Release Tag for Pre-Release Packages:
>> 0.%{X}.%{alphatag}
>>Release Tag for Non-Numeric Post-Release Packages:
>> %{X}.%{alphatag}
>>
>>Where %{X} is the vepoch increment, and %{alphatag} is the string that
>>came from the version.
>>
>>Example (pre-release):
>> mozilla-1.4a.tar.gz from usptream is lower than
>> mozilla-1.4.tar.gz the later "final" version thus
>> mozilla-1.4-0.1.a Fedora package name
>>
>>Example (pre-release):
>> alsa-lib-0.9.2beta1.tar.gz becomes
>> alsa-lib-0.9.2-0.1.beta1
>>
>>Example (post-release):
>> gkrellm-2.1.7.tar.gz
>> gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7
>> gkrellm-2.1.7-1.a
>
>
> For gkrellm is this necessary? rpm considers 2.1.7a newer than
> 2.1.7 already unless something has changed. Another package of
> this nature is UW imap. It is generally released with an integer
> based version number of the year of it's release, possibly
> followed by a single letter indicating a revision within that
> year. ie: imap-2000 imap-2000a imap-2000b
>
> In rpm's normal operation these packages are naturally treated as
> the older package on the left, with the newer ones proceeding to
> the right.
>
> My personal preference would be to just let rpm assume that as it
> should work. I've never gotten bug reports of it not working
> anyway. Moving things from the version to the release field
> unnecessarily just complicates packaging when there's no real
> benefit IMHO. For the pre-release cases above it makes sense as
> it's being done in order to override rpm's default behaviour,
> which would be to treat what is a final release as older than a
> prerelease.
>
> I believe treating both pre-release and post-release in the same
> manner just for consistency with both types of lettered versioned
> packages is just cosmetic consistency, but doesn't provide any
> functional or technical benefit. In other words, sticking with
> the upstream version in the version field is IMHO best unless
> there is a technical benefit of doing so, such as avoiding having
> to later use Epoch to override a prerelease build.
>
> Are there cases where rpm would consider imap-2000a as older than
> imap-2000?
>
> jbj?
>
Err... you are completely right about it not being necessary in the
post-release case. I am not sure why our fedora.us policy retained that
even though it was unnecessary for all these months. The way I
understand the older version of rpm broken rpmvercmp behavior, this
wouldn't be a problem with those versions too.
* To be able to go back from 2.1.7a to a patched 2.1.7 in case the
2.1.7a post-release "fix" turns out to cause side-effects.
* Consistency above all.
* The road of least surprise (with regard to upstream versioning).
* To help avoid that users think foo-1.0a would be an unstable alpha
version, when in fact it is a post-release patch-level.
--