"Spec" is missing information it eludes to.

[smaillet]

The CSemVer "spec" is missing a lot of critical information to make it truly useful. In particular, the following are referenced in the spec but not actually defined there:

1. Short form
   1. This form is mentioned and a few examples provided but not defined formally in the spec leaving users to guess at what it is expected to be.
   2. Examples alone are not enough and the one's given are actually contradictory.
      1. '1.0.0-b03-01' AND '5.0.0-r-04-13' are shown, but which is correct?
         1. Is the delimiter between the short name and number components required or not?
2. Conversion of a CSemVer into an ordered version number
   1. It is suggested this is plausible, but no formal specification of HOW this is done is provided in the spec. One is left to figure it out by looking at the examples, or reverse engineer the "explore" site. Neither is a particularly great story for a spec.
3. Conversion to a Windows style VERSION quad is not specified
   1. Again, no specification of how to compute such a thing is defined (it is suggested but frustratingly NOT defined in the spec)
   2. After futzing with the Explore site it was discovered that File version "Revision" numbers with an "odd" value are reserved for CI builds. Leading to an assumption that a FileVersion is a 64-bit unsigned value that is the ordered number shifted by 1 bit with the least significant bit then as either 0 (Not a CI build) or 1 (A CI Build), but again not specified.

[smaillet]

Additional issues:
As mentioned above the FILE VERSION "quad" is considered to include the CI build status as an ODD numbered revision field. This means that comparison of the unsigned 64-bit integral value of a file version does NOT produce a validly ordered version. (A CI build should always have a lower sort order than a non-CI build of the same major, minor, and patch.) Worse, it means that the Windows OS version comparison support will produce incorrect ordering. Thus, it is recommended to invert the nature of that bit. That is convert from an "Is CI version" to "Is Release Version". So EVEN numbered revisions are reserved for CI builds and always compare the ordering correctly.

Important

The claims in this comment are incorrect and a result of confusion on the point of where a CI build is ordered in relation to a release. See additional comments for clarity.

[smaillet]

OK, for the record, the CI status of a File version as implemented in the "playground" is correct. Though I'd maintain my initial argument that the spec is missing information and that the nature of a CI version is confusing at best without clarification. Specifically, it is worth identifying that a CI build version is what comes AFTER a release. (Most people think of a CI build as what comes before a release so there's an inherent ambiguity on the point)

[smaillet]

In addition to the omissions identified in my original post on this issue the CSemVer-CI spec has no formal syntax - only examples. The examples from section 2 and 6 seem to imply that the CSemVer-CI can ONLY have Build meta if it is Zero-Timed. The release-based forms illustrated in section 6 do NOT include build meta (was that an accidental omission or is there a reason?). Bear in mind that a Breaking change in .NET SDK 8
is now setting the build meta data for the InformationalVersion property automatically. This behavior is subtle and implemented with a controversial OPT-OUT model. It has no awareness of CSemVer-CI and if there is a reason why Build meta is forbidden on "last release" based CI builds, then that needs clarification as the default behavior for .NET is to add that onto the end automatically!