That's fine and I generally agree with you, but "humans are bad at big numbers" doesn't seem like a good rationale for choosing a data type for a computer to use to represent a piece of information as part of an API that isn't allowed to change. Computers are fine with arbitrarily large numbers, and in particular, Linux capable platforms are absolutely great at 32 or 64 bit numbers depending on their architecture. Using 8 bit integers seems like it could have been premature optimization. If the original API had just used "int" without thinking about it too much, it would have had the same practical performance as using an 8-bit type, and would have worked up to at least 2 billion on any reasonable platform. Maybe the API needed a guaranteed fixed size across platforms, though, and the original designer thought more than 255 minor versions was crazy?
Solving the "large version numbers are bad for this project" problem is a human policy concern, and probably better done via education/documentation or an explicit warning in code (like a compiler warning or console message if the version number is more than 3 base-10 digits.)
I’m not familiar with the code. But my assumption is that it’s not that they chose to use an 8 bit integer for the y-version field. It’s that they chose to use a 24-bit number for the whole version. OxXXYYZZ - Eg 0x050801 for kernel version 5.8.1. That lets you compare kernel version A with kernel version B using a simple u32 cmp. They could have used 16 bits per version field - but that would have needed a 64 bit integer, which is much slower on some of the systems Linux used to run on back when that decision was made. In retrospect that was a bad choice, but I’m sure it seemed fine in the 90s.
The problem is that if they spill the minor version to 16 bits (xxyyyyzz) then kernel version 4.256.1 is “newer than” kernel 5.8.1 - because 0x04010001 > 0x00050801. And that’s a compatibility breaking change.
Solving the "large version numbers are bad for this project" problem is a human policy concern, and probably better done via education/documentation or an explicit warning in code (like a compiler warning or console message if the version number is more than 3 base-10 digits.)