Introduce `CustomVersion` variable
Introduces a new output variable CustomVersion and an associated formatting variable custom-version-format
Description
Intent is to allow the user to define an output variable without changing the semantics of existing ones. This can then be used to resolve issues such as providing an appropriate version to tools such as NuGet which do not fully followed semantic versioning rules.
Related Issue
Motivation and Context
See above
How Has This Been Tested?
Additional tests in ConfigurationProviderTest for custom-version-format and updated test outputs elsewhere to align
Checklist:
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
@arturcic Why did you revert the doc change on my branch?
Also, confused as to why some of the App tests are failing e.g. WixVersionFileContentTest doesn't have the CustomVersion output, but the module tests pass.
Is there another mechanism other than GitVersionVariables that I need to update?
One other question is whether the changes should be under the 6.4 schema or be bumped to a 6.5 schema?
One other question is whether the changes should be under the 6.4 schema or be bumped to a 6.5 schema?
The schema is updated as part of the release
@arturcic Why did you revert the doc change on my branch?
Also, confused as to why some of the App tests are failing e.g.
WixVersionFileContentTestdoesn't have theCustomVersionoutput, but the module tests pass.Is there another mechanism other than
GitVersionVariablesthat I need to update?
That's not me who updated, but of you want to change the configuration.md you need to update mdsource instead
Can we approve this now or is there something else to do?
Can I just do a squash commit/rebase to tidy the commits up - surely you do a squash on merge anyway?
Can I just do a squash commit/rebase to tidy the commits up - surely you do a squash on merge anyway?
No, we don't do squash merge commits. We like to keep the commit history and merge commits, but in this case it's a bit messy. If you want to rebase and squash everything into one commit, that's fine by me. 👍🏼
Also, not sure how to address the flaky windows/qodana builds
Also, not sure how to address the flaky windows/qodana builds
No, it seems unrelated to this PR. I'm hoping @arturcic has an idea.
Also, not sure how to address the flaky windows/qodana builds
No, it seems unrelated to this PR. I'm hoping @arturcic has an idea.
I noticed that as well, not much we can do at this point. We can re-run the failed jobs for the windows and that will succeed the second time, qodana usually fails whenever the global.json sdk is updated, it takes time for their action to update for the latest sdk
Quality Gate passed
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.3% Duplication on New Code
@asbjornu I've squashed the commits, is there anything else I need to do?
Bad merge - I’ll add it backSent from my iPhoneOn 21 Sep 2025, at 16:41, Asbjørn Ulsberg @.***> wrote: @asbjornu approved this pull request.
Just one last question, otherwise this looks good to me!
In docs/input/docs/usage/cli/arguments.md:
@@ -113,13 +113,13 @@ Double quote character inside of the double quoted
valuehas to be be escaped
Following options are supported:
-1. assembly-file-versioning-format
Why is assembly-file-versioning-format removed?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>