I have doubts if between the prefix and the dist tag is really where this kind of stuff would be desirable. At least it has potential to break between distro upgrades (assuming by "allow for upgrade paths" you mean that you'd like the next upstream package release to update your custom version).

{{{
$ rpmdev-vercmp 1.0-1.fc13 1.0-1.foo.fc13
0:1.0-1.foo.fc13 is newer
$ rpmdev-vercmp 1.0-1.fc14 1.0-1.foo.fc13
0:1.0-1.foo.fc13 is newer
}}}

Appending something at the end of the release tag would not have this problem, and would be even easier to implement (perhaps by changing the -r option to take the desired string as an optional argument, and use that instead of .1 if set). Or did I miss something?

Oops. I had forgotten about that case. Appending to the very end is indeed the better solution. I'll get another patch spun tomorrow.

Updated. Now always puts the string at the end (-s implies -r to do this).

Hmm. I see another case:

{{{
% rpmdev-vercmp 1.0-1.fc13.256color 1.0-1.fc13.1
0:1.0-1.fc13.256color is newer
}}}

Patch updated to support this case.

attachment
0001-Allow-the-user-to-bump-with-a-custom-string.patch

Sorry, I somehow missed the previous revision of your patch. But if I guess what changed in the latest revision, I don't think it's desirable - if one adds something to the EVR, there's no way to ensure that it will always be considered older than the next upstream revision, so I don't think it's worth it to cover one specific case. And in this revision the documentation of -s no longer matches what it actually does. The patch also broke -r for specfiles with revisions like 1%{?dist}.1 ("TypeError: cannot concatenate 'str' and 'NoneType' objects").

Alternative implementation committed as [27e50bb] - this one is in my opinion enough and adds the possibility to do the same -s foo invocation multiple times and it'll do trailing foo1, foo2 etc.