On Tue, 05 Jun 2012 14:05:13 +0400, Pavel Alexeev wrote:
> 04.06.2012 22:26, Michael Schwendt написал:
>> On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:
>>
>>> Additionally have worth I try read carefully all docs about
>>> provenpackager and such updates and have not found how deal with such
>>> versions.
>> It's not provenpackager specific stuff, but found in the basic packaging
>> guidelines:
>>
>>
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7...
>>
>>> I had look in my packages and few others and found it was
>>> updated many times in that way.
>> Just read the page linked above. There is no strict requirement to
>> apply this release versioning scheme for old branches. If newer branches
>> would always win RPM Version Comparison because their %version field
>> is _higher_, you can bump %release in older branches without risk.
>>
>>> In packages were was present subrelease
>>> after %{?dist} - I increase it.
>>> Should or must in next time I add it in any package even it does not
>>> have it??
>> As the guidelines say: "Be careful with this!"
> Thank you very much Michael. It's helpful.
> But what still is not clear to me - if it secure, may it be applied to
> all packages on update in stable releases? Or instead I should check if
> increasing release do not break version sequence in branches - do that.
> And only if it false, introduce subrelease like %{?dist}.1?
Well, if you want to spare yourself the extra check, simply use the
%{?dist}.N scheme for old branches _always_. Then you're on the safe side.
[That means: If you see only a %{?dist} in an old branch, introduce the
%{?dist}.N scheme even if it's not strictly necessary. If you see the
%{?dist}.N scheme is used already, increase N appropriately. Then it's
up to the package owner, or anyone else who touches the package, to
check whether the normal %{?dist} scheme would be fine when preparing
another bug-fix release sometime after you.]