Document the upgrade steps and always print them after a release
Readers and future sessions need one obvious place that says how to move
an installed app to the latest version, and the release flow now requires
surfacing those commands in every release report.
💘 Generated with Crush
Assisted-by: Crush:deepseek-v4.1-flash
This commit is contained in:
@@ -79,6 +79,20 @@ ad-hoc signing (`-`) if none is present. `LSUIElement` is true → no Dock icon.
|
||||
Bump `CFBundleShortVersionString`/`CFBundleVersion` via the `build-app.sh`
|
||||
version argument and pass the same version to `release.sh`.
|
||||
|
||||
## Release process
|
||||
|
||||
1. `./release.sh <version>` — builds, zips `SimpleTopBar.app` to
|
||||
`dist/SimpleTopBar.zip`, and prints its sha256 (it does not tag or upload).
|
||||
2. Commit and push `main`.
|
||||
3. `tea releases create --tag v<version> --asset dist/SimpleTopBar.zip --repo TZGyn/simpletopbar --login gitea.tzgyn.dev`.
|
||||
4. Bump `version`/`sha256` in `~/.cache/homebrew-tap/Casks/simpletopbar.rb`,
|
||||
push, then `git -C /opt/homebrew/Library/Taps/tzgyn/homebrew-tap pull --ff-only`.
|
||||
|
||||
**Always print the upgrade script after any release or version bump** — the user
|
||||
wants it in the final answer every time. Keep it to the cask upgrade commands
|
||||
(see the README release section for the exact block), because the app is
|
||||
installed through the tap.
|
||||
|
||||
## Gotchas
|
||||
|
||||
- `AppListModel` is `@MainActor`; the `NSWorkspace` observers hop back with
|
||||
|
||||
Reference in New Issue
Block a user