[Starlingx-discuss] discuss about initial value of TIS_PATCH_VER when upgrade packages

[Chris Friesen]

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