That sounds like an RPM bug, can you file it up there?

Probably parsing the number? And because the hex part from the "higher" version only has one leading digit but the "lower" version's hex part starts with more digits, the sorting is "reversed" from what you expect because the hash leaks into the number that's being compared?

I'd add some kind of separator, something like .git between date and short hash, that should work.

The version comparison seems to fail because the second hash digit is a letter and not a number:

$ rpmdev-vercmp 1.7.0~202307168 1.7.0~202307090
1.7.0~202307168 > 1.7.0~202307090
$ rpmdev-vercmp 1.7.0~202307168f 1.7.0~2023070906
1.7.0~202307168f < 1.7.0~2023070906
$ rpmdev-vercmp 1.7.0~202307168f 1.7.0~2023070906
1.7.0~2023071681 > 1.7.0~2023070906

I've filed https://github.com/rpm-software-management/rpm/issues/2574

To clarify, I don't think this is a bug. Most C functions to parse numbers (like strtol) will parse digits until the first invalid character. Just concatenating number + commit hash is prone to fail because commit hashes are hexadecimal, not decimal, so you will get numbers with different amount of digits.

This is why I use a period to separate them, so they don't get misinterpreted. For example: 0~git20201202.0e32b92 for obs-studio-plugin-webkitgtk

Yeah, you need to use a separator character here if you mix different "data types" (i.e. decimal date, string / hexadecimal commit hash, etc.), otherwise you will get wrong results.