I agree that we'd eventually want to switch to "stx" instead of "tis". The way that we did it previously was to consistently have the meaning of the ".x" be "the number of changes made to the upstream package". So the first time you make a change it'd be ".1", then you make another change and it'd be ".2", and then if you upgrade to a newer base package but keep both changes it'd have a new upstream base version but still be ".2" for the version suffix. For what it's worth, CentOS and Debian do things a bit differently. When they move to a new upstream version of the package they switch back to "-1" regardless of the number of patches . So you'd have something like 0.14.0-1, then 0.14.0-2, then 0.15.2-1. OpenSUSE has a more complicated suffix like "-5.3.1", I'm not sure what their rules for updating it are. Given the above, I could see a rationale for reducing confusion by aligning with CentOS and switching back to ".1" when bumping upstream versions. But I still think there is value in the previous mechanism as it gives a general idea of how much a given package differs from upstream. Chris On 1/7/2019 5:48 PM, Saul Wold wrote:
I also think we should really be switching to stx.0, but that's a different discussion I would guess.
<snip>
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.