05.06.2012 16:09, Michael Schwendt wrote:
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.7B.3Fdist.7D_Tag
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.]
Ok, thank you for the explanation.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
