An additional section was added to the Packaging/NamingGuidelines
Package Release section:
The old text described post releases as:
Post-release packages: Packages released after a "final" version.
This usually is due to a quick bugfix release, such as openssl-0.9.6b or
gkrellm-2.1.7a. In this case, the non-numeric characters are permitted
in the Version: field.
The text has now been amended to:
Post-release packages: Packages released after a "final" version.
These packages contain the same numeric version as the "final" version,
but have an additional non-numeric identifier.
Details can be found here: Non-Numeric Version in Release
Also, a new section under Non-Numeric Version in Release has been added
for Post Release Naming:
Post-Release packages
Like pre-release packages, non-numeric versioned "post-release" packages
can be problematic and also must be treated with care. These fall under
two generic categories:
* Properly ordered simple versions. These are usually due to quick
bugfix releases, such as openssl-0.9.6b or gkrellm-2.1.7a. As
new versions come out, the non-numeric tag is properly
incremented (e.g. openssl-0.9.6c) or the numeric version is
increased and the non-numeric tag is dropped (openssl-0.9.7). In
this case, the non-numeric characters are permitted in the
Version: field.
* When upstream uses versions that attempt to have meaning to
humans instead of being easy for a computer to order. For
example, GA1, CR2, PR3. In this case, the non-numeric string can
be put in the Release: field using the following syntax:
%{X}.%{posttag}
In this syntax, %{X} is the release number increment, and %{posttag} is
the string that came from the version. Here, the period '.' should be
used as the delimiter between the release number increment, and the
non-numeric version string. No other extra characters should appear in
the Release field.
Example (complicated post-release):
foo-1.1.0-0.1.BETA (this is a prerelease, first beta)
foo-1.1.0-0.2.BETA1 (this is a prerelease, second beta)
foo-1.1.0-0.3.BETA2 (this is a prerelease, third beta)
foo-1.1.0-0.4.CR1 (this is a prerelease, candidate release 1)
foo-1.1.0-0.5.CR2 (this is a prerelease, candidate release 2)
foo-1.1.0-1 (final release)
foo-1.1.0-2.GA1 (post release, GA1)
foo-1.1.0-3.CP1 (post release, CP1, after GA1)
foo-1.1.0-4.CP2 (post release, CP2, after CP1)
foo-1.1.0-5.SP1 (post release, SP1, after CP2)
foo-1.1.0-6.SP1_CP1 (post release, SP1_CP1, after SP1)
It is important to be careful with the post-release scheme, to ensure
that package ordering is correct. It may be necessary to use Epoch to
ensure that the current package is considered newer than the previous
package. In such cases, the packager should try to convince upstream to
be more reasonable with their post-release versioning.
Also, packagers using the post-release scheme should put a comment in
their spec file with a brief description of the upstream conventions for
naming/versioning that are being worked around.
This change was approved by the Fedora Packaging Committee and ratified
by FESCO.
~spot
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
