When we customize an upstream package for the first time, TIS_PATCH_VER gets set to 1, then generally gets incremented on each subsequent change. Thus, prior to package upgrade TIS_PATCH_VER reflects the number of changes that were made to the upstream package. This can be used to tell at a glance how customized a given package is. When upgrading, it's possible that some customizations are no longer applicable, while others are. Thus, I think options "a" and "e" don't make sense as they remove the "how customized is this package" meaning. Of the options below, I think option "c" is probably the best since for an upgrade we might create a single meta-patch to add all the source patches. I think the most accurate value would probably be "number of source patches" plus "number of meta patches that don't add/remove source patches". But we probably don't really need that level of accuracy. Chris On 1/4/2019 2:28 AM, An, Ran1 wrote:
Hi all I'm sending this to discuss about the rule of initial value of TIS_PATCH_VER when srpm package is upgraded. "TIS_PATCH_VER" is a counter to indicate change within a major version of the package, on which we put patches.
When I upgraded srpms(related to CentOS) from CentOS 7.5 to 7.6, there are different voices about the initial value of TIS_PATCH_VER(comments on [1][2][3][4]): a). reset it to 0 b). reset to the number of STX patches remaining (source patches and meta_patches together) c). reset to the number of STX patches remaining (source patches only) d). reset to the number of STX patches remaining (meta patches only) e). case by case, better do not reset.
It is not a technical issue, but we will face it each time we upgrade packages, so which would you like to choose?
[1] https://review.openstack.org/#/c/627760/ [2] https://review.openstack.org/#/c/627750/ [3] https://review.openstack.org/#/c/627156/ [4] https://review.openstack.org/#/c/627770/
Thanks Ran