# Release management

ResizeMe follows the Tiny Clips model: one semantic version can produce independent macOS and Windows releases. Release tags name the target platform:

```text
v<major>.<minor>.<patch>-mac
v<major>.<minor>.<patch>-windows
```

The checked-in release manager creates annotated tags only after the application version files match the selected version and the working tree is clean. It also reports the latest remote release tags and every checked-in distribution version.

## Check release state

Fetch tags first so the report includes all historical releases, then run the command for your shell:

```powershell
git fetch origin --tags
.\scripts\release.ps1 -Status
```

```sh
git fetch origin --tags
./scripts/release.sh --status
```

The report covers the native macOS project and Info.plist, Sparkle appcast, Homebrew cask, Wails application, winget manifests, and both latest remote platform tags. The appcast and cask are generated release metadata, so they may intentionally remain on the previously published version until the next macOS release completes.

## Release Hub canvas

The committed **ResizeMe Release Hub** canvas provides the same information and guarded release flow in the Copilot app. Open it to review every version source, suggested platform tag, GitHub Release, workflow run, Homebrew/Sparkle metadata, and winget status in one place.

Each state-changing operation requires an exact typed confirmation. **Demo Mode** simulates tagging, pushing, workflow dispatch, and winget submission without changing Git or GitHub.

## Prepare and tag a release

1. Promote the matching Unreleased entries in `CHANGELOG.md` to `## [X.Y.Z] - YYYY-MM-DD`. See [changelog.md](changelog.md).
2. Set the version in the source files for each platform being released:

   | Platform | Required source files |
   | --- | --- |
   | macOS | `ResizeMeMac/project.yml` and `ResizeMeMac/ResizeMe/Resources/Info.plist` |
   | Windows | `ResizeMe/wails.json` |

3. Commit and push those changes to `main`.
4. Create and push the selected tags:

   ```powershell
   .\scripts\release.ps1 v1.0.3 -Mac -Windows -Push
   ```

   ```sh
   ./scripts/release.sh v1.0.3 --mac --windows --push
   ```

   Pass one platform option to release only that platform. Omit `-Push` or `--push` to create tags locally and review them before pushing. PowerShell also supports `-WhatIf`; the shell script supports `--dry-run`.

## Distribution workflows

| Platform | Tag workflow | Publishing result | Follow-up |
| --- | --- | --- | --- |
| macOS | `macOS Release` | Signed, notarized GitHub Release ZIP; Sparkle appcast; Homebrew cask metadata | Verify the GitHub Release and Sparkle update path. |
| Windows | `Windows Release` | Signed x64 and ARM64 GitHub Release executables and generated winget manifests | Run `WinGet Submission` with the Windows tag and monitor the `microsoft/winget-pkgs` pull request. |

Both release workflows can also be run manually from **Actions** with an existing tag. They check out that tag, validate its format, and publish the matching platform release. This is useful for rerunning a failed release without creating a second tag.

The macOS workflow stamps the archive's `CFBundleShortVersionString` from the tag and assigns the GitHub Actions run number as `CFBundleVersion`; it then commits only the generated appcast and cask metadata to `main`. The Windows workflow stamps the Wails build version from the tag and leaves source manifests intact while it generates release-specific winget manifests.

See [changelog.md](changelog.md) for the required PR and release-note flow, [macos-release-checklist.md](macos-release-checklist.md) for signing and notarization prerequisites, and [windows-winget-setup.md](windows-winget-setup.md) for Windows signing and winget submission secrets.