Releasing

Releasing

Each release publishes four self-contained builds of PCEdit.Desktop to a GitHub Release, plus SHA256SUMS.txt.

Platform	Artifact	Built on
Linux	PCEdit-<version>-<build>.x86_64.AppImage	ubuntu-22.04 (oldest practical glibc)
Windows	PCEdit-<version>-win-x64.zip	windows-latest
macOS (Intel)	PCEdit-<version>-macos-x64.zip	macos-latest
macOS (Apple Silicon)	PCEdit-<version>-macos-arm64.zip	macos-latest

The <build> in the AppImage name is the workflow run number (e.g. PCEdit-1.5.0-16.x86_64.AppImage).

What the checksums prove. SHA256SUMS.txt ships in the same Release as the files it describes, so it proves a download arrived intact — not who made it. None of the artifacts is code-signed; the trust anchor is the repository and its release workflow.

The repository's own copy of this procedure is RELEASING.md.

Versioning — one source of truth

The version lives in one place: <VersionPrefix> in the repo-root Directory.Build.props. Every project inherits it, every packaging script reads it, and the Release workflow stamps it into the assemblies with -p:Version=.

Rules the pipelines enforce:

• CI (version-guard) fails a PR if <VersionPrefix> is not X.Y.Z, or if it is behind the newest vX.Y.Z tag. It warns once <VersionPrefix> has caught up to the latest release tag — that warning is the reminder to bump before the next release.
• Release refuses to build if a pushed tag disagrees with <VersionPrefix>, if a manual run targets a version whose tag already exists, or if a manual run is not on main.

Cutting a release

1. Bump the version. Edit <VersionPrefix> in Directory.Build.props (semver), add the CHANGELOG.md entry, open a PR, get CI green, merge to main. In practice this happens inside the feature PR — see Contributing — which is what keeps main releasable at all times.

2. Trigger the Release workflow, either:

• From GitHub (recommended): Actions → Release → Run workflow → branch main. It reads <VersionPrefix>, creates the vX.Y.Z tag on the current main, builds all four artifacts, and publishes the Release with auto-generated notes.

• By tag: create and push it yourself; it must match <VersionPrefix> exactly.

  git checkout main && git pull
  git tag "v$(sed -n 's|.*<VersionPrefix>\([^<]*\)</VersionPrefix>.*|\1|p' Directory.Build.props)"
  git push origin --tags

3. Wait for the four build jobs, then check the drafted-then-published Release.

4. Add the macOS note to the Release body — manually. The auto-generated notes list merged PRs and never mention that the macOS build is unsigned. Append:

---

### macOS

The macOS `.zip` contains an **unsigned** `PCEdit.app`. On first launch, right-click the
app and choose **Open** (or run `xattr -dr com.apple.quarantine PCEdit.app`).

And call out any user-visible packaging change in the same section. PR titles almost never convey that the download itself behaves differently — a notable size change, a new or dropped runtime dependency, a renamed or added artifact, a raised minimum OS. Say what changed, by how much, and why, and say who is not affected: a reader who sees "+13 MB" on Linux will wonder about their own platform. The same entry belongs in CHANGELOG.md, which is what people read before downloading.

Worked example — v1.2.1. Bundling ICU took the AppImage from 43.0 MB to 56.5 MB. Its notes lead with those numbers, give the reason (it would not start at all on a distro with no system libicu), and state that Windows and macOS are unchanged.

5. Bump again for development. Raise <VersionPrefix> to the next planned version on main so pre-release builds are not stamped with the shipped version. That bare bump carries no changelog entry — the entry arrives with the change that fills the version.

Before you release

• Both test projects green on main.
• Generated files committed in sync (CI enforces this).
• The Linux portability matrix green on the CI-built AppImage — see Building & Packaging.
• CHANGELOG.md has an entry for the version being released.
• This wiki and the repository docs are audited against the release — README, RELEASING.md, deploy/README.md, the tool READMEs and every wiki page the release touched — so documentation does not go stale release by release. Check names, counts, button labels and artifact names against the code and the actual release assets.

Local packaging

Local builds are for testing only — never ship them, particularly on Linux, where the build host's glibc becomes the artifact's floor.

deploy/build-appimage.sh
deploy/build-windows.ps1
deploy/build-macos.sh osx-arm64

Each restores once and then publishes with --no-restore, because the committed lock files describe a restore with no RuntimeIdentifier — see Building & Packaging.