<!-- When a build number is specified, it needs to be in the format of 'x.y'-->
<!-- When a build number is specified, it needs to be in the format of 'x.y'-->
<ErrorCondition="$(BuildNumber.Split($([System.Convert]::ToString(`.`).ToCharArray())).Length) != 2">BuildNumber should have two parts (in the form of 'x.y')</Error>
<ErrorCondition="$(BuildNumber.Split($([System.Convert]::ToString(`.`).ToCharArray())).Length) != 2">BuildNumber should have two parts (in the form of 'x.y')</Error>
...
@@ -38,12 +42,15 @@
...
@@ -38,12 +42,15 @@
BuildNumberBuildOfTheDayPadded: 01;and the 12th build of the day, 20160615.12, will produce BuildNumberFiveDigitDateStamp: 60615, BuildNumberBuildOfTheDay: 12
BuildNumberBuildOfTheDayPadded: 01;and the 12th build of the day, 20160615.12, will produce BuildNumberFiveDigitDateStamp: 60615, BuildNumberBuildOfTheDay: 12
Additionally, in order ensure the value fits in the 16-bit PE header fields, we will only take the last five digits of the BuildNumber, so
Additionally, in order ensure the value fits in the 16-bit PE header fields, we will only take the last five digits of the BuildNumber, so
in the case of 20160615, we will set BuildNumberFiveDigitDateStamp to 60615. Unfortunately for releases in 2017 we can't go any higher, so
in the case of 20160615, we will set BuildNumberFiveDigitDateStamp to 60615. Further, if this would result in a number like 71201 or 81201, we
well continue the month counting instead: the build after 61231 is 61301. -->
decrement the year and add 12 to the month to extend the time. -->