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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
