Well…it’s similar, but not exactly, really. Pungi (or rather productmd, which is where all the rules for this sort of thing actually come from) doesn’t exactly have a “version number” concept.
There *is * a clearly defined concept called the ‘compose ID’. The compose ID of this compose is “Fedora-Rawhide-20190629.n.0”. There is also a clearly defined metadata property called the date: for the compose (which is a defined productmd property) the date is “20190629”. Ditto respin, which for this compose is “0”.
But what rpm-ostree puts into the os-release file is “Rawhide.20190629.n.0”. That’s not the compose ID, or the date, or the respin; it’s closest to the compose ID, but it clearly isn’t the same. Nothing else that I’m aware of uses a string quite like that, or would expect to process one that looks like that. Notably, just from looking at that string I am not confident I can predict for sure what that string would be in all conditions, because I can’t be sure how it’s being produced. Does rpm-ostree understand pungi compose types, such that for a Final candidate compose the string would be ‘31.20190901.0’ (note: no ‘.n.’), or is the ‘.n.’ just being cargo-culted into place? What’s that string going to be for post-release stable composes, which have compose IDs like “Fedora-29-updates-20190715.0” ? Is that “-updates-” going to wind up in this version string or not? It’s hard to be sure.
I do get the idea of trying to provide the most specific information possible about “what this ostree actually is”. My concern is just that this seems to have been sort of cooked up ad hoc for Silverblue and isn’t necessarily defined or documented anywhere as a value anyone would expect, and if someone looks at the values they find in any other Fedora install and expects to find something similar in Silverblue they might be surprised.
Basically I’d expect there to be consistency/predictability across Fedora editions and spins as to what you’re going to find in os-release (and similar files), and I’m not sure if right now the practices / policies are in place to ensure this…for instance, is the fedora-release maintainer aware that this modification happens in Silverblue?