On 27. 02. 20 9:20, Pierre-Yves Chibon wrote:
> How would that work with "complex" releases? For
example release containing
> prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package
> have no version, so depend heavily on the Release tag to signal what is the
> snapshot date and git commit packaged.
This is something that we will need to investigate and clarify a little more,
the answer may very well be: it won't, but let's investigate this first.
There are three ways of of there I can think of ATM:
1. (as said by Pierre) make it opt-in only and don't handle this
2. (as said by Neal) don't do this, use 0.1~beta.2-<release>
3. allow to keep the Release filed if it uses %{baserelease}
%{baserelease} is already respected by rpmdev-bumpspec (and hence mass rebuilds)
%global baserelease 8
Release: iamcrazy1234568andIknowit.%{baserelease}.whatnot~foo666%{?dist}
bumpspec does:
%global baserelease 9
Release: iamcrazy1234568andIknowit.%{baserelease}.whatnot~foo666%{?dist}
So we can reuse that and say: If the Release is manually defined in spec and
uses %{baserelease} and %{baserelease} is not defined in spec, the automation
sets the %{baserelease} value instead of setting the release directly.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok