The nuget target's built-in version bumper silently skips Directory.Build.props — the idiomatic SDK-style version file for multi-project .NET repos — and downgrades the failure to a warning, letting prepare continue with the stale version number.
From the craft prepare log in a real broken release (getsentry/sentry-dotnet@6.6.0):
[info] Running automatic version bumping from targets...
[debug] Running version bump for target "nuget"...
[debug] dotnet-setversion not available, falling back to manual edit
[debug] Target "nuget" did not apply (detection failed)
[warn] Targets [nuget] support version bumping but did not find applicable
files in your project. Consider adding a preReleaseCommand if you
need custom version bumping.
The result: every .nupkg published to NuGet and attached to the GitHub release carried the previous version number (*.6.5.0.nupkg inside a 6.6.0 release). NuGet rejected the upload as duplicates of the existing packages, so nothing landed. The release had to be fully rolled back and re-cut.
Root cause — two compounding issues:
Directory.Build.props is not in the nuget target's recognized file list. The bumper falls back to dotnet-setversion, and when that CLI is absent, detection fails entirely.- Failure is downgraded to
warn rather than error, so prepare continues and commits/tags with the wrong version.
Suggested fixes:
- Add
Directory.Build.props (and optionally Directory.Packages.props) to the nuget target's file detection so the built-in bumper works for SDK-style repos without requiring dotnet-setversion.
- When version bump detection fails for a target that declares
versioning support, treat it as a hard error and abort prepare rather than continuing.
References:
Action taken on behalf of Johannes Daxboeck.
The nuget target's built-in version bumper silently skips
Directory.Build.props— the idiomatic SDK-style version file for multi-project .NET repos — and downgrades the failure to a warning, lettingpreparecontinue with the stale version number.From the craft prepare log in a real broken release (getsentry/sentry-dotnet@6.6.0):
The result: every
.nupkgpublished to NuGet and attached to the GitHub release carried the previous version number (*.6.5.0.nupkginside a6.6.0release). NuGet rejected the upload as duplicates of the existing packages, so nothing landed. The release had to be fully rolled back and re-cut.Root cause — two compounding issues:
Directory.Build.propsis not in the nuget target's recognized file list. The bumper falls back todotnet-setversion, and when that CLI is absent, detection fails entirely.warnrather thanerror, sopreparecontinues and commits/tags with the wrong version.Suggested fixes:
Directory.Build.props(and optionallyDirectory.Packages.props) to the nuget target's file detection so the built-in bumper works for SDK-style repos without requiringdotnet-setversion.versioningsupport, treat it as a hard error and abortpreparerather than continuing.References:
preReleaseCommandAction taken on behalf of Johannes Daxboeck.