[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