Skip to content

Release Process

Jump to bottom
gokuthug1 edited this page Oct 5, 2026 · 1 revision

Release Process

The workflow

.github/workflows/ci-release.yml runs on every push and pull request.

Build job

Runs on windows-latest with the .NET 6 SDK:

  1. Checkout — including submodules.
  2. Setup .NET — 6.0.x.
  3. Restore dependencies.
  4. Build — Release.
  5. Feature and WPF safety checks — the same command contributors run locally: 
    dotnet run --project tests/GokuTrap.FeatureChecks -c Release -- "${{ github.workspace }}"
  6. Publish — single-file, framework-dependent, win-x64, stamped with the commit SHA and ref.
  7. Upload artifact — the resulting GokuTrap.exe.

Release job

Runs on ubuntu-latest, needs build, and is gated:

if: startsWith(github.ref, 'refs/tags/v')

A release is produced only from a v-prefixed tag. Pushing to main builds and uploads an artifact but publishes no release. That is why ordinary pushes do not surprise users with a new download.

Making a release

  1. Ensure main is green.
  2. Create and push a v-prefixed tag: 
    git tag v3.1.3
git push origin v3.1.3
  3. The release job runs and publishes.

Asset format

Property Value
Platform win-x64
Deployment Single file, framework-dependent (--self-contained false)
Requires The .NET desktop runtime on the user's machine

Framework-dependent is deliberate: it keeps the download small and leaves runtime patching to Windows/.NET servicing.

In-app updates

The updater consumes these releases. For an update to be offered correctly, the release must:

  • carry a version the app recognises as newer (omitted trailing zeros compare equal, so 3.1.2 and 3.1.2.0 are the same),
  • contain a Windows x64 executable asset,
  • and, ideally, publish a SHA-256 digest for it.

A release with no supported x64 asset is reported as ineligible rather than being downloaded blindly. See Application-Updates.

About the digest

The digest is published by GitHub alongside the asset, in the same API response. GokuTrap verifies it for consistency, not publisher identity, and the UI says exactly that. See Downloads-and-Verification.

What CI does not verify

CI cannot run a real Roblox session. The live-game behaviours listed in Verification-Harness#What the harness does not cover remain manual acceptance items in docs/FEATURE_DELIVERY.md.

Branch protection expectations

For a change to reach users:

Version numbering

Semantic-style major.minor.patch, with the tag matching the version users see in About.

Prereleases exist. They are opt-in in the updater — see Application-Updates#Options — so a prerelease never reaches a user who has not asked for it.

Clone this wiki locally