You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Formatting of pre-release numbers for CI builds should ALWAYS include the pre-release number and fix for a pre-release build.
* Moved non-test functionality into Support namespace to help clarify role
* Clarified docs on behavior of CI version
- Clearly that's a complex and subtle point!
Copy file name to clipboardExpand all lines: docfx/build-tasks/UnderstandingCIBuilds.md
+26-17Lines changed: 26 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,14 @@ Hopefully examples will make things more clear:
32
32
* As with the previous example this is ordered AFTER the release it is based on
33
33
and BEFORE the Patch+1 version (`v5.0.4-beta.0.1`).
34
34
35
+
>[!NOTE]
36
+
> As [[BUG] - CI version string formatting does not ALWAYS include pre-release information for a pre-release](https://github.com/UbiquityDotNET/CSemVer.GitBuild/issues/72)
37
+
> points out the formatting of pre-release version numbers is different in CSemVer-CI. In a CI
38
+
> version the `Number` and `Fix` values are ALWAYS included, even if `0`. In a CSemVer
39
+
> things are more complex. In such a case, the `Number` and `Fix` are NOT shown if 0.
40
+
> ***Unless*** the `Number` is `0` AND `Fix > 0` in that case the `Number` is shown
41
+
> as a zero and the `Fix` is shown as it's non-zero value.
42
+
35
43
## lifetime scope of a CI Build
36
44
The lifetime of a CI build is generally very short and once a version is released
37
45
all CIs that led up to that release are essentially moot.
@@ -99,18 +107,18 @@ on the ordered integral form of the version and increments that, until it reache
99
107
maximum)
100
108
101
109
### Ordered Version
102
-
Ordered versions are a concept unique to Constrained Semantic versions. The constraints
103
-
applied to a SemVer allow creation of an integral value for all versions, except CI
104
-
builds. Ignoring CI builds for the moment, the ordered number is computed from the
105
-
values of the various parts of a version as they are constrained by the CSemVer spec.
106
-
The math involved is not important for this discussion. Just that each Constrained
107
-
Version is representable as a distinct integral value (63 bits actually). A CSemVer-CI
108
-
build has two elements the base build and the additional 'BuildIndex' and 'BuildName'
109
-
components. This means the string, File version and ordered version numbers are
110
-
confusingly different for a CI build. The ordered version number does NOT account for
111
-
CI in any way. It is ONLY able to convert to/from a CSemVer. Thus, a CSemVer-CI has
112
-
an ambiguous conversion. Should it convert the Patch+1 form in a string or the
113
-
base build number?.
110
+
Ordered versions are a concept unique to Constrained Semantic versions. The
111
+
constraints applied to a SemVer allow creation of an integral value for all versions,
112
+
except CI builds. Ignoring CI builds for the moment, the ordered number is computed
113
+
from the values of the various parts of a version as they are constrained by the
114
+
CSemVer spec. The math involved is not important for this discussion. Just that each
115
+
Constrained Version is representable as a distinct integral value (63 bits actually).
116
+
A CSemVer-CI build has two elements the base build and the additional 'BuildIndex' and
117
+
'BuildName' components. This means the string, File version and ordered version
118
+
numbers are confusingly different for a CI build. The ordered version number does NOT
119
+
account for CI in any way. It is ONLY able to convert to/from a CSemVer. Thus, a
120
+
CSemVer-CI has an ambiguous conversion. Should it convert the Patch+1 form in a string
121
+
or the base build number?
114
122
115
123
### File Version Quad and UINT64
116
124
A file Version quad is a data structure that is blittable as an unsigned 64 bit value.
@@ -153,10 +161,11 @@ Bits 1-63 are the same as the ordered version of the base build for a CI build a
153
161
the same as the ordered version of a release build.
154
162
155
163
------
156
-
<sup><aid="footnote_1">1</a></sup> Endianess of the platform does not matter as the bits are numbered as MSB->LSB
157
-
and the actual byte layout is dependent on the target platform even though the bits
158
-
are not. It is NOT safe to transfer a FileVersion (or Ordered version) as in integral
159
-
value without considering the endianess of the source, target and transport mechanism,
160
-
all of which are out of scope for this library and the CSemVer spec in general.
164
+
<sup><aid="footnote_1">1</a></sup> Endianess of the platform does not matter for the
165
+
purposes of discussion or this library, as the bits are numbered as MSB->LSB and the
166
+
actual byte layout is dependent on the target platform even though the bits are not.
167
+
It is NOT safe to transfer a FileVersion (or Ordered version) as in integral value
168
+
without considering the endianess of the source, target and transport mechanism, all
169
+
of which are out of scope for this library and the CSemVer spec in general.
0 commit comments