Update versioning scheme to ensure monotonic build numbers#13
Conversation
Updated both the GitHub Actions workflow and JobTracker.csproj to add a build offset of 500 to the build number, ensuring new versions are always higher than previous ones, even after changing the versioning logic. Adjusted comments and logic to reflect the new scheme.
Qodana for JVMIt seems all right 👌 No new problems were found according to the checks applied ☁️ View the detailed Qodana report Contact Qodana teamContact us at qodana-support@jetbrains.com
|
There was a problem hiding this comment.
Pull request overview
Updates the app/package versioning scheme so CI build numbers remain monotonic across a versioning-logic change, and aligns the GitHub Release tag with the new computed build number.
Changes:
- Add a
BuildOffsetinJobTracker.csprojand apply it to CI/localBuildRevisioncalculation. - Update the GitHub Actions release tag generation to add the same offset to
github.run_number.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| JobTracker.csproj | Introduces BuildOffset and updates BuildRevision computation used in the app/MSI version. |
| .github/workflows/dotnet.yml | Adjusts the generated release tag to use run_number + 500. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <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> |
There was a problem hiding this comment.
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.
| <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). --> |
There was a problem hiding this comment.
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.
| 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. --> |
| 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)" |
There was a problem hiding this comment.
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.
| TAG="v1.$(date -u +%y).${BUILD_NUM}.$(date -u +%m%d)" | |
| TAG="v1.$(date +%y).${BUILD_NUM}.$(date +%m%d)" |
Updated both the GitHub Actions workflow and JobTracker.csproj to add a build offset of 500 to the build number, ensuring new versions are always higher than previous ones, even after changing the versioning logic. Adjusted comments and logic to reflect the new scheme.