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