https://bugzilla.redhat.com/show_bug.cgi?id=1775667
--- Comment #4 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Quote:
The methods for dealing with most of these issues involves potentially removing
some information from the Version: tag while imposing additional structure onto
the Release: tag. There are potentially four fields which comprise the
structured Release: tag:
package release number (<pkgrel>)
extra version information (<extraver>)
snapshot information (<snapinfo>)
minor release bump (<minorbump>)
The package release number MUST always be present while the others may or may
not be depending on the situation.
Those items which are present are combined (with periods to separate them) to
construct the final Release: tag. In the usual notation where square brackets
indicate that an item is optional:
<pkgrel>[.<extraver>][.<snapinfo>]%{?dist}[.<minorbump>]
YYYYMMDD<scm><revision> is the snapinfo part of the equation, you still need
the <pkgrel>, which start at 1 for released version or 0.1 for prerelease:
Prerelease versions
In the Version: tag, use the version that upstream has determined the next
release will be. For the field of the Release: tag, use a number of the form
"0.N" where N is an integer beginning with 1 and increasing for each revision
of the package. Prerelease versions MUST use a Release: tag strictly less than
1, as this is the sole indicator that a prerelease has been packaged.
> Also consider using macros to simplify updating.
not sure what do you mean?
I mean using the %{shortcommit} macro in Release so you don't have to charge
it every release:
Release: 1.20191119git%{shortcommit}%{?dist}
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component