> So what is to be done? As of this writing that has not yet been worked out, but there are a couple of options on the table... Stable maintainer Greg Kroah-Har

> So what is to be done? As of this writing that has not yet been worked out, but there are a couple of options on the table... Stable maintainer Greg Kroah-Hartman suggested that he could "leave it alone and just see what happens". But, as Slaby pointed out, that will create the wrapping problem described above, which could confuse user space. If this is done, he said, it would be necessary to mask the minor version to eight bits, causing it to wrap back around to zero; whether that would cause confusion is another question. Version numbers are normally expected to increase monotonically. Apparently with the exception of the masking to 8 bits, it seems like that's what's being tried in the end[1][2][3]: > I did a release of the 4.4.256 and 4.9.256 releases today that contain nothing but a new version number. > With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0). > Right now I’m asking that everyone who uses these older kernel releases to upgrade to this release, and do a full rebuild of their systems in order to see what might, or might not, break. If problems happen, please let us know on the stable@vger.kernel.org mailing list as soon as possible as I can only hold off on doing new stable releases for these branches for a single week only (i.e. February 12, 2021). [1] 8 Bits Are Enough for a Version Number -- https://news.ycombinator.com/item?id=26037687 https://news.ycombinator.com/item?id=26037687 [2] https://lore.kernel.org/lkml/1612534196241236@kroah.com/ https://lore.kernel.org/lkml/1612534196241236@kroah.com/ [3] https://lore.kernel.org/lkml/1612535085125226@kroah.com/ https://lore.kernel.org/lkml/1612535085125226@kroah.com/