RedHat Enterprise Linux actually solved this with their kABI. This allows vendors to ship binary driver RPMs for kernels in the same RHEL major version (eg, RHEL 4, RHEL 5, etc). However, this entails a major effort on the part of RHEL, as it forces them to carefully backport improvements from upstream in a slow and careful way, so as to avoid breaking binary compatibility.
The RHEL kABI model was quite nice to deal with as a 3rd party NIC vendor (and you had to do it, even if you upstreamed your drivers, as they were frequently not backported to RHEL/Centos at a rapid clip, so RHEL customers would be using ancient buggy drivers unless you put together a driver RPM for them).
However, the source changes to support all the backports were something else entirely (which you needed if you wanted support for newly backported features). For a 10GbE driver that was roughly 2000 lines of C, I had a roughly 1000 line hand-made configure script, roughly 1/2 which was checks made necessary due to RHEL's backports. Checks that could have been a simple check to see what the linux kernel version was were complex spaghetti, trying to detect how many arguments some function took. This is because EVERY kernel was 2.6.18 for RHEL5, even if it had backports from 10 or more versions higher.
I'm guessing that Google felt that it was better to invest in building an OS they could control from the ground up, rather than hiring a building full of people to backport upstream patches in a binary compatible way.
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.
RedHat Enterprise Linux actually solved this with their kABI. This allows vendors to ship binary driver RPMs for kernels in the same RHEL major version (eg, RHEL 4, RHEL 5, etc). However, this entails a major effort on the part of RHEL, as it forces them to carefully backport improvements from upstream in a slow and careful way, so as to avoid breaking binary compatibility.
The RHEL kABI model was quite nice to deal with as a 3rd party NIC vendor (and you had to do it, even if you upstreamed your drivers, as they were frequently not backported to RHEL/Centos at a rapid clip, so RHEL customers would be using ancient buggy drivers unless you put together a driver RPM for them).
However, the source changes to support all the backports were something else entirely (which you needed if you wanted support for newly backported features). For a 10GbE driver that was roughly 2000 lines of C, I had a roughly 1000 line hand-made configure script, roughly 1/2 which was checks made necessary due to RHEL's backports. Checks that could have been a simple check to see what the linux kernel version was were complex spaghetti, trying to detect how many arguments some function took. This is because EVERY kernel was 2.6.18 for RHEL5, even if it had backports from 10 or more versions higher.
I'm guessing that Google felt that it was better to invest in building an OS they could control from the ground up, rather than hiring a building full of people to backport upstream patches in a binary compatible way.