Skip to content

feat: add edge prerelease channel and start stable at 0.1.0 (PROT-40)#4

Merged
BlakeHastings merged 2 commits into
mainfrom
feat/PROT-40-edge-channel
Jun 1, 2026
Merged

feat: add edge prerelease channel and start stable at 0.1.0 (PROT-40)#4
BlakeHastings merged 2 commits into
mainfrom
feat/PROT-40-edge-channel

Conversation

@BlakeHastings
Copy link
Copy Markdown
Member

Summary

Adds a rolling edge prerelease channel and fixes the initial stable version. protostar now ships on two tracks, matching how Claude Code, rustup, and GoReleaser-based CLIs do it.

Jira: PROT-40

Track Trigger Version (MinVer) Release Install
stable merge the release-please Release PR 0.1.0 vX.Y.Z, normal release (releases/latest) --channel stable (default)
edge every code change to main 0.1.0-alpha.0.N moving edge tag, prerelease, assets replaced --channel edge

What's in here

1. Edge channel — .github/workflows/edge.yml

  • Triggers on push to main, path-filtered to src/**, **/*.csproj, Directory.Build.props, and the workflow itself (docs/CI-only merges don't rebuild).
  • Builds the 4-platform matrix, then one job re-points the edge tag at the new commit and replaces the prerelease's assets via the gh CLI (no new third-party actions). Delete + recreate keeps the download URLs stable (releases/download/edge/<asset>).
  • concurrency: edge with cancel-in-progress so overlapping merges don't fight over the release.
  • Actions pinned to commit SHAs (same standard as PR ci: pin workflow actions to commit SHAs (PROT-39) #3).

2. Installer channel selection — scripts/install.{sh,ps1}

  • New --channel stable|edge (sh) / -Channel stable|edge (ps1), default stable. stable pulls releases/latest, edge pulls releases/download/edge. Same asset names, so only the URL differs.

3. Initial stable version fix

  • release-please defaults a project's first release to 1.0.0 (it ignores pre-major options when the manifest is 0.0.0 — their issue #2087). We're pre-1.0. Setting the manifest + version.txt to 0.0.1 and adding bump-minor-pre-major makes the first release compute as 0.1.0, and keeps future breaking changes inside 0.x.

Why it composes

The edge tag doesn't start with v, so MinVer ignores it — the edge channel can't perturb stable version computation, and release-please only manages its own v* tags. No collisions.

Side effects after merge

  • The open release-please Release PR (currently "release 1.0.0") will recompute to 0.1.0.
  • Because the edge build is path-filtered to code, a release-please Release-PR merge (which only touches version.txt/CHANGELOG/manifest) won't trigger an edge rebuild.

Verify

dotnet run --project src/Protostar.Cli -- --version   # untagged main -> 0.1.0-alpha.0.N (the edge version)
sh -n scripts/install.sh                              # installer parses

🤖 Generated with Claude Code

BlakeHastings and others added 2 commits June 1, 2026 11:09
Adds a rolling 'edge' prerelease channel: edge.yml rebuilds the tip of main on code changes and replaces a single prerelease under the moving 'edge' tag (versioned by MinVer, e.g. 0.1.0-alpha.0.N). The installers gain --channel stable|edge to pick the track. Stable stays on release-please.

Also fixes the first stable version: release-please defaults the first release to 1.0.0, but we are pre-1.0. Set the manifest and version.txt to 0.0.1 and add bump-minor-pre-major so the first release computes as 0.1.0 and breaking changes stay in 0.x.

Refs: PROT-40

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
So the edge channel reports 0.1.0-alpha.0.N before the first v0.1.0 tag exists, instead of 0.0.0-alpha. Stable (tagged) builds are unaffected.

Refs: PROT-40

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@BlakeHastings BlakeHastings merged commit 66e887a into main Jun 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants