Ship 3.0.0. <Version> is already 3.0.0 in CSharpExtender/CSharpExtender.csproj, and the Release workflow reads the version back off the packed file, so the tag and the release title cannot disagree with the package.
The upload to nuget.org is done by hand, deliberately. Nothing in this repo pushes to nuget.org and nothing is going to. See "Why the push is manual" below.
Steps
- Check
RELEASE_NOTES.md has a ## Version 3.0.0 section. Without one the release falls back to GitHub's generated notes, and the PackageReleaseNotes link in the csproj points at RELEASE_NOTES.md at the v3.0.0 tag, so the section wants to exist before the tag is cut.
- Run the Release workflow from the Actions tab. It is
workflow_dispatch only, and draft defaults to true.
- Review the draft release, then publish it. That creates tag
v3.0.0 and a release titled Version 3.0.0, with the .nupkg and the .snupkg attached.
- Download both the
.nupkg and the .snupkg from the release.
- Upload the
.nupkg at https://www.nuget.org/packages/manage/upload. Check the description, the icon, the release notes link and the listed dependencies on the preview before submitting.
- Upload the
.snupkg at the same page, after the .nupkg for that version has finished. nuget.org takes the symbol package as a separate upload and attaches it to the version already there, so the order matters: a symbol package for a version that is not published yet is rejected.
- Confirm the new version appears on https://www.nuget.org/packages/ScottLilly.CSharpExtender once indexing finishes, which usually takes a few minutes.
- Close the
Version 3.0.0 milestone.
Why the push is manual
Decided 21 September 2026, replacing the automated-deployment issue that used to sit on this milestone. Automating dotnet nuget push saves one upload per release, a few times a year, and costs a long-lived nuget.org API key living in a repository secret plus the risk of a mis-triggered workflow publishing something that was not meant to go out. A push to nuget.org cannot be undone: a version can be unlisted but never deleted or replaced, and the version number is consumed permanently.
The workflow's job stops at producing the artifacts and the GitHub Release. The decision to publish stays a human one.
Do not raise an issue to automate this, and do not add a NUGET_API_KEY secret.
Ship 3.0.0.
<Version>is already3.0.0inCSharpExtender/CSharpExtender.csproj, and the Release workflow reads the version back off the packed file, so the tag and the release title cannot disagree with the package.The upload to nuget.org is done by hand, deliberately. Nothing in this repo pushes to nuget.org and nothing is going to. See "Why the push is manual" below.
Steps
RELEASE_NOTES.mdhas a## Version 3.0.0section. Without one the release falls back to GitHub's generated notes, and thePackageReleaseNoteslink in the csproj points atRELEASE_NOTES.mdat thev3.0.0tag, so the section wants to exist before the tag is cut.workflow_dispatchonly, anddraftdefaults to true.v3.0.0and a release titledVersion 3.0.0, with the.nupkgand the.snupkgattached..nupkgand the.snupkgfrom the release..nupkgat https://www.nuget.org/packages/manage/upload. Check the description, the icon, the release notes link and the listed dependencies on the preview before submitting..snupkgat the same page, after the.nupkgfor that version has finished. nuget.org takes the symbol package as a separate upload and attaches it to the version already there, so the order matters: a symbol package for a version that is not published yet is rejected.Version 3.0.0milestone.Why the push is manual
Decided 21 September 2026, replacing the automated-deployment issue that used to sit on this milestone. Automating
dotnet nuget pushsaves one upload per release, a few times a year, and costs a long-lived nuget.org API key living in a repository secret plus the risk of a mis-triggered workflow publishing something that was not meant to go out. A push to nuget.org cannot be undone: a version can be unlisted but never deleted or replaced, and the version number is consumed permanently.The workflow's job stops at producing the artifacts and the GitHub Release. The decision to publish stays a human one.
Do not raise an issue to automate this, and do not add a
NUGET_API_KEYsecret.