So, taking a tangent here... If you fork, and that includes backporting security fixes upstream won't, you need a new version.
Obviously, you can't just take .28, apply a fix, and call it .29... But you have to do something.. ideally something that indicates binary ABI compat with upstream .28, (so software vendors can just decide, your .28, you get .28 features.
Maybe something like SemVer needs a model for versioning of forks? (I'm not a SemVer fan or hater, it's just the best known effort in this area..)
It has been several years, but I'm sure there was a version. However, part of the problem was that it wasn't just RHEL that backported stuff. Other distros (like SLES) did similar things. In the end, it was just easier to do a configure-ish script to see if a function foo() took 3 or 4 arguments than it was track N-different version numbers.
And you're right, if you always build on the base version, then you have greater compat. However, you also loose out on the backported features, many of which were important for performance.
Obviously, you can't just take .28, apply a fix, and call it .29... But you have to do something.. ideally something that indicates binary ABI compat with upstream .28, (so software vendors can just decide, your .28, you get .28 features.
Maybe something like SemVer needs a model for versioning of forks? (I'm not a SemVer fan or hater, it's just the best known effort in this area..)