Skip to content

Update versioning scheme to ensure monotonic build numbers #13

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
raymondjstone merged 1 commit into from
Apr 9, 2026
Merged

Update versioning scheme to ensure monotonic build numbers #13

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion .github/workflows/dotnet.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,8 @@ jobs:
- name: Generate version tag
id: version
run: |
TAG="v1.$(date -u +%y).${{ github.run_number }}.$(date -u +%m%d)"
BUILD_NUM=$(( ${{ github.run_number }} + 500 ))
TAG="v1.$(date -u +%y).${BUILD_NUM}.$(date -u +%m%d)"
Copy link

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The release tag uses UTC dates (date -u) while the project version uses System.DateTime::Now (local time). Around midnight (or if runner time zones differ), this can produce a tag that doesn't match the built MSI/app version for the same run. Consider using UTC consistently on both sides (switch csproj to UtcNow or remove -u here) to keep tags and artifacts aligned.

Suggested change
TAG="v1.$(date -u +%y).${BUILD_NUM}.$(date -u +%m%d)"
TAG="v1.$(date +%y).${BUILD_NUM}.$(date +%m%d)"

Copilot uses AI. Check for mistakes.
echo "tag=$TAG" >> "$GITHUB_OUTPUT"
echo "Version: $TAG"

Expand Down
10 changes: 6 additions & 4 deletions JobTracker.csproj
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,13 +5,15 @@
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<BlazorDisableThrowNavigationException>true</BlazorDisableThrowNavigationException>
<!-- Version: 1.YY.BuildNumber.MMdd
<!-- Version: 1.YY.BuildNumber+500.MMdd
MSI only compares the first 3 fields for upgrade detection (4th is ignored).
The build number (which changes every CI run) MUST be in the 3rd field,
otherwise same-day builds produce duplicate entries in Apps & Features.
CI uses github.run_number; local builds fall back to HHmm. -->
<BuildRevision Condition="'$(BUILD_NUMBER)' != ''">$(BUILD_NUMBER)</BuildRevision>
<BuildRevision Condition="'$(BUILD_NUMBER)' == ''">$([System.DateTime]::Now.ToString("HHmm"))</BuildRevision>
CI uses github.run_number; local builds fall back to HHmm.
BuildOffset ensures new versions (1.26.500+) are higher than old scheme (1.25.MMDD). -->
Copy link

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The explanation of the offset looks internally inconsistent: the comment says versions are 1.YY.BuildNumber+500.MMdd, but also claims the offset makes 1.26.500+ higher than an old 1.25.MMDD scheme. Since MSI compares the first 3 fields, 1.26.* is already higher than 1.25.* regardless of offset; if the intent is to prevent downgrades within the same YY when switching schemes, update the comment to describe that scenario and the required bounds for the offset.

Suggested change
BuildOffset ensures new versions (1.26.500+) are higher than old scheme (1.25.MMDD). -->
BuildOffset is only relevant when changing schemes within the same YY value:
it must make the new 3rd field larger than any legacy 3rd-field value used
by the old scheme for that same YY. A different YY (for example 1.26.* vs
1.25.*) is already ordered correctly by MSI without any offset. -->

Copilot uses AI. Check for mistakes.
<BuildOffset>500</BuildOffset>
<BuildRevision Condition="'$(BUILD_NUMBER)' != ''">$([MSBuild]::Add($(BUILD_NUMBER), $(BuildOffset)))</BuildRevision>
<BuildRevision Condition="'$(BUILD_NUMBER)' == ''">$([MSBuild]::Add($([System.DateTime]::Now.ToString("HHmm")), $(BuildOffset)))</BuildRevision>
Comment on lines +14 to +16
Copy link

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MSI/ProductVersion segments must be <= 65535. With BuildRevision = BUILD_NUMBER + BuildOffset, the version will eventually exceed this limit once github.run_number grows past ~65035, which will break builds/installer upgrades. Consider capping or resetting the 3rd field (e.g., roll the major/minor/year when approaching the limit, or compute a bounded monotonic value per year) so the generated version always stays within MSI constraints.

Copilot uses AI. Check for mistakes.
<Version>1.$([System.DateTime]::Now.ToString("yy")).$(BuildRevision).$([System.DateTime]::Now.ToString("MMdd"))</Version>
<DefaultItemExcludes>$(DefaultItemExcludes);JobTracker.Tests\**</DefaultItemExcludes>
<ApplicationIcon>wwwroot\favicon.ico</ApplicationIcon>
Expand Down
Loading