Automate the creation of GitHub releases

[nojaf]

I don't know how releases are made today, but if those (and I mean the publish to NuGet) happen automatically, I would appreciate automated GitHub releases as well.
These can nowadays easily be created via the GitHub CLI.

[github-actions]

---

Note

The pull request was not created — a fallback review issue was created instead due to protected file changes: #1744

🤖 This is an automated response from Repo Assist.

Great suggestion, @nojaf! Looking at the current push-master.yml workflow:

• ✅ NuGet publish is already fully automated (runs on every merge to main, uses --skip-duplicate to avoid re-publishing)
• ❌ GitHub releases are not created — the last one was 6.3.0 in September 2023, but NuGet has since had many more releases (current version is 8.1.8)

I've just opened a draft PR that adds a "Create GitHub release (if new version)" step after the NuGet publish step. The implementation:

1. Reads the version from RELEASE_NOTES.md
2. Checks if a release for that version already exists (idempotent)
3. If not, extracts the release notes for that version and calls gh release create, attaching the .nupkg files as assets

It uses only GITHUB_TOKEN and the gh CLI (pre-installed on GitHub Actions runners) — no new dependencies.

The PR is: #1744 (or check the latest [Repo Assist] PR in the PR list)

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[dsyme]

@nojaf Why do we need GitHub releases too? Can we just have the nuget releases? I'm just wondering

I don't know how releases are made today, but if those (and I mean the publish to NuGet) happen automatically, I would appreciate automated GitHub releases as well.

[dsyme]

@nojaf

Why do we need GitHub releases too? Can we just have the nuget releases? I'm just wondering

I'm happy to arrange for GitHub releases, but I guess I'm wondering what tooling consumes GitHub releases of .NET packages that can't also consume packages from nuget.org. Is it the case that some enterprises only allow consumption of GitHub releases?

[github-actions]

🤖 This is an automated response from Repo Assist.

Good question, @dsyme. Here's a balanced take:

Reasons GitHub releases add value beyond NuGet:

1. Watch notifications — GitHub users who "Watch → Releases Only" get an email/notification when a new release is published. NuGet has no equivalent opt-in notification mechanism.
2. In-repo changelog UI — the Releases page shows a formatted version history directly in the GitHub UI, which many contributors check before deciding whether to upgrade.
3. Source archives — each release automatically provides .tar.gz/.zip source archives (useful for mirrors, vendors, or reproducibility).
4. Dependabot/Renovate — these tools primarily use the NuGet API, not GitHub releases, for .NET packages. No benefit here.

Reasons NuGet alone may be sufficient:

• For pure .NET library consumption (which is FSharp.Data's use case), NuGet is the definitive source. GitHub releases do not need to contain .nupkg files for most users.
• Enterprises using internal NuGet proxies (Azure Artifacts, JFrog) are already set up to mirror packages from nuget.org — they don't consume GitHub releases.

My assessment: the main concrete benefit is watch notifications and the changelog UI. PR #1750 implements this by attaching .nupkg files as release assets, which is nice but not required — a simpler version that just creates a tagged release with notes (no assets) would still achieve the notification/changelog benefits with less CI complexity.

Ultimately this is a stylistic/UX preference — worth it if @nojaf or other users care about the release feed, easy to skip if not.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[dsyme]

@nojaf if it's OK let's not do this. I'd have to do it for other libraries (FSharp.Control.AsyncSeq etc.) and I'd prefer to keep a tight ship with just to one release channel, unless there are clients that can't consume that

[nojaf]

Hi @dsyme, sorry for the slow reply — I was moving to a new place.

I hear you, but I do think it's worth reconsidering. Setting up GitHub releases is honestly not much work, and the benefits are real: people can subscribe to release notifications directly from the repo, Dependabot PRs get proper release notes, and it's just good open-source practice. The automated bot above laid it out pretty well.

I get that you'd want consistency across your other libraries, but that's also an argument for doing it — set it up once with a reusable
workflow and all your projects benefit.

Up to you of course, but I would still do this.