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

[Saul Wold]

On 1/7/19 7:28 AM, Scott Little wrote:
> 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?I would have thought that the tis.<x> extension would be enough to 
indicate this package had patches.

I also think we should really be switching to stx.0, but that's a 
different discussion I would guess.

> 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 guess I am about the consistency of the meaning of tis.<x> when it 
increments, such that starting at 0 and later incrementing means change 
occurs vs starting at N want meaning a patch count and later 
incrementing and not really having a meaning any more, my OCD kind of 
kicks in.


> 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.
> 
As I said, I had never heard this until now, I understand your busy, but 
we did the whole 7.5 update without hearing about.

> 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.
> 
Do we need a proper Specification for the meaning of the package 
information, this is where we can change the tis/TIS to stx/STX!

Sau!

> 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
>