1. 18
  1. 3

    It seems the conclusion isn’t “8 bits are enough for a version number” and rather “a bunch of userspace software ASSUMED 8 bits would be enough for a version number, so we better just stick with it if we don’t wanna break stuff”

    1. 6

      Userspace didn’t just assume that though, it was built into the way that the version codes are exposed in the userspace headers. And with the overflowed version there are now multiple kernel versions that userspace can no longer tell apart by comparing those version codes.

      1. 2

        Sounds like a terrible solution to me. Why not clamp the version number instead, so 4.9.255 and 4.9.256 are the same kernel.

        1. 1

          I think that’s probably the best idea, given the intent of the stable release trains appears to be stability. Saturate the version at the maximum that can be expressed without breaking anything and then provide a new interface for a more fine grained number for software that needs to be able to tell; e.g., 4.9.255.1, 4.9.255.2 and so on.