Purpose:
There is a need to handle post-release tags in a similar fashion to pre-release tags.
Currently, the Packaging/NamingGuidelines establish:
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.
I propose that the text be amended:
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
Then, add the following as a subitem under Non-Numeric Version in Release
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.