[closer-claudio]

The kernel's release tag was X.Y.Z-ossein.N: distro-kernel style, no v, chosen so that GitHub's "Latest" and sort -V would not read a v-prefixed, hyphen-suffixed tag as a pre-release of X.Y.Z. It was the one farcloser release shape outside limen's book: a repackaging's rebuild of upstream X.Y.Z is vX.Y.Z.N (book/forks.md), a fourth segment that sorts after X.Y.Z and before the next upstream, and limen's release lane, canonical Renovate rule and registry-ref check take that shape and no other (farcloser/limen#635).

What changes. just release-kernel takes vX.Y.Z.N. X.Y.Z must still equal the pinned kernel source; N is the rebuild number, from 1, reset to 1 on a source bump. The kernel's localversion, which was the tag minus the upstream version, is ossein.N, so uname -r still names the release (7.2.9-ossein.1 for v7.2.9.1) and a running kernel still identifies itself; the ossein flavor and every other recipe are unchanged. The README's releasing section follows. Published releases keep their tags.

For a consumer. A pin that reads the kernel's tags with a versioning written for X.Y.Z-ossein.N (ossein's guest-kernel pin) does not parse vX.Y.Z.N: on the first release under the new shape, the pin moves by hand to it, and its versioning to the shared v-prefixed rule limen's canonical Renovate configuration carries, or to regex:^v(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)\.(?<build>\d+)$ until that configuration reaches it.

Evidence. The pre-flight check, probed alone with the pin at 7.2.9: v7.2.9.1 and v7.2.9.12 accepted, with localversion ossein.1 and ossein.12; 7.2.9-ossein.1, v7.2.9, v7.2.8.1, v7.2.9.1x, v7.2.9.1.2, v7.2.91 and 7.2.9.1 refused. just lint, just test and just do lint commits are green. The release itself is cut by hand on a VZ host, so the recipe's build half is exercised at the next release, not in CI.