AArnott on main
Update doc links Force non-shallow clones Fixes… Switch to using dotnet-coverage… and 6 more (compare)
AArnott on libtemplate
AArnott on libtemplate
Update doc links Force non-shallow clones Fixes… Switch to using dotnet-coverage… and 5 more (compare)
-blswitch to msbuild or
dotnet buildand collect the resulting msbuild.binlog file as an artifact. Then open that file using the tool at https://msbuildlog.com and see whether your target runs and what (else) happens to those properties that you're setting.
nerdbank.gitversioning\3.4.244\build\MSBuildCore\LibGit2Sharp.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\NerdBank.GitVersioning.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\Nerdbank.GitVersioning.Tasks.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\Newtonsoft.Json.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\Validation.dll
Is it a bug that NBGV uses the new version number from an uncommited version.json but ignores changes to the prerelease-tag?
In an uncommited version.json I can change the version number and nbgv get-version will print the new version directly, without commiting. Changes to the prerelease -tag are completely ignored until I commit the changes.
version.jsonfile that sets the version to
1.2.3-alphaand your stable branch set to
1.2.2(or whatever you most recent stable version was). When your 1.2.3 development branch becomes stable, you remove the
-alphasuffix from the
version.jsonfile for that branch. Does that help?
mainbranch where I'm developing 1.1-alpha, then I may want the
v1.0branch to periodically merge into
mainso that v1.1 will release with all the same fixes that v1.0 had. Nerdbank.GitVersioning works naturally with this because
mainwill have the most recent change to
version.jsonso a merge from
v1.0will not touch version.json, leaving both branches building the version they mean to.
1.2.3-alphabranch merges into a
1.2.3branch. What becomes of the source branch at that point? Does it remain
1.2.3-alphaor does it advance to
1.2.4? And was the target branch
1.2.3before and after the merge?
develop's merge to
mainthat the team of devs working in
developwould have to 'slow down' and not destabilize the branch. The way I and teams around me have done it is work never slows in the primary dev branch, and stabilization happens after branching off, which gives a fine opportunity to change the version.json file. In fact this is so common we have the
nbgv prepare-releasecommand which automates branching off for stabilization that automatically trims the
-prereleasetag on the servicing branch and advances the unstable version from 1.2.3 to 1.2.4 or whatever the policy is that you set in version.config.
develophave conflicting changes for version.json, your gitattributes file could allow git merge to work without conflicts and just leave the copy in the target branch alone.
AfterTargets="GetBuildVersion"attribute, you can review and edit any of the many msbuild properties that NB.GV sets. You could consider the active branch name (
BuildingRef) property and remove the -prerelease tag from the version when the branch being built is
GitVersionBaseDirectoryproperty (or environment variable) to specify where to look for the version.json file. So you could have two version files, in two different directories, and have a github action in your workflow set the
GitVersionBaseDirectoryenv var based on the branch being built to achieve what you want.
pathproperty is documented as a root below the config file, or do I misunderstand the usage and it could be a config file? I'm not using MSBuild, I'm using the github actions workflow and I'm using dotnet publish, see https://github.com/ptr727/PlexCleaner/blob/develop/.github/workflows/BuildPublishPipeline.yml
-prereleasetag, but not the minor version.
GetBuildVersion. A bunch of msbuild properties are set by that target and you can read them and rearrange them all you want.
nbgv get-versioncommands will no longer work for you.