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

Scott Little scott.little at windriver.com
Mon Jan 7 15:28:36 UTC 2019


I disagree.   Our experience in the past, is that putting a tis.0 on a 
package raises questions from both customers and designers.  Why are you 
compiling this at all if you aren't changing it?

A little digging, and some wasted cycles, and the answer is.  "Oh, we 
are changing it. we still have 3 patches against it. sorry for the 
confusion."

Now as you point out.  We might remove a patch in a non-rebase context.  
In this case we are compelled to increment, rather than decrement, 
TIS_PACTH_VER.  In this case we have to live with the misleadingly high 
number until the next rebase.  That's ok.  No one has complained about that.

I should have been flagging this in earlier code reviews.  I wasn't.  My 
error.  Had bigger fish to fry in the early months of going open source.

If the community wants to overrule, that's fine.  I'm just trying to 
share my hard won experience as 'the rebase guy' for 4 years prior to 
open sourcing.

Scott



On 2019-01-04 4:52 p.m., Saul Wold wrote:
>
> I am not sure I agree with any of this, first off, just the fact that 
> we have an SRPM and the TIS_PACTH_VER indicates that it's been 
> patched, I really don't see the value in having the patch count 
> indicated as a "Version" item.
>
> It makes more sense to start from 0 (option a) and that way we can 
> track each subsequent change to that package with an increment.
>
> This issue did not come up at all in past updates, I am not sure why 
> it's becoming an issue now.
>
> See below for additional comments




More information about the Starlingx-discuss mailing list