The published v0.1.1 release points at ef1a9e5. main is at 3aac02a, six commits later, and those commits contain two user-facing fixes the release does not have:
427b0fe — Quit in the menu bar did nothing. NSMenuItem leaves target nil, so the action went to the responder chain, AgentController is not in it, and AppKit disabled the item.3aac02a — launching the app with no arguments printed usage and exited 2, so there was no way to reopen it after quitting. It now runs the agent, which is what double-clicking a .app should do.
Also in the gap: acf466d (--help performed a real install; the binary check had no timeout), 2eaeabf (TCC grants reset on every Developer ID rebuild), 93be7cf (flaky CI), b054d9d (cask/installer conflict).
Why it matters
drycodeworks/tap serves the release asset, so brew install --cask drycodeworks/tap/tacet currently installs a build whose Quit button is dead.
There is a mild silver lining: because Quit does not work in v0.1.1, a user cannot reach the state where they need the reopen fix. The two defects mask each other. That is luck, not design, and it stops being true the moment either one ships alone.
What to do
Cut v0.1.2:
- Bump
CFBundleShortVersionString to 0.1.2 and CFBundleVersion to 3 in swift/Packaging/Info.plist
- Build and sign — needs an Aqua session, or the dedicated-keychain recipe, since
codesign returns errSecInternalComponent under launchctl managername: Background
ditto -c -k --keepParent, notarize with --key/--key-id/--issuer, staple, re-zip the stapled bundle- Tag, release, then update
Casks/tacet.rb in DRYCodeWorks/homebrew-tap — version and sha256 — via PR, since test-bot only exercises a cask on a PR
Blocked on, or at least entangled with
The cask should not be recommended until #25 is understood: the v0.1.1 bundle hangs at _dyld_start when run from /Applications, while the identical bytes run fine from ~/Applications. Shipping v0.1.2 into the cask does not fix that, and may reproduce it. Worth resolving #25 first, or at least checking whether v0.1.2 reproduces it before updating the cask.
The published v0.1.1 release points at
ef1a9e5.mainis at3aac02a, six commits later, and those commits contain two user-facing fixes the release does not have:427b0fe— Quit in the menu bar did nothing.NSMenuItemleavestargetnil, so the action went to the responder chain,AgentControlleris not in it, and AppKit disabled the item.3aac02a— launching the app with no arguments printed usage and exited 2, so there was no way to reopen it after quitting. It now runs the agent, which is what double-clicking a.appshould do.Also in the gap:
acf466d(--helpperformed a real install; the binary check had no timeout),2eaeabf(TCC grants reset on every Developer ID rebuild),93be7cf(flaky CI),b054d9d(cask/installer conflict).Why it matters
drycodeworks/tapserves the release asset, sobrew install --cask drycodeworks/tap/tacetcurrently installs a build whose Quit button is dead.There is a mild silver lining: because Quit does not work in v0.1.1, a user cannot reach the state where they need the reopen fix. The two defects mask each other. That is luck, not design, and it stops being true the moment either one ships alone.
What to do
Cut v0.1.2:
CFBundleShortVersionStringto0.1.2andCFBundleVersionto3inswift/Packaging/Info.plistcodesignreturnserrSecInternalComponentunderlaunchctl managername: Backgroundditto -c -k --keepParent, notarize with--key/--key-id/--issuer, staple, re-zip the stapled bundleCasks/tacet.rbinDRYCodeWorks/homebrew-tap— version and sha256 — via PR, since test-bot only exercises a cask on a PRBlocked on, or at least entangled with
The cask should not be recommended until #25 is understood: the v0.1.1 bundle hangs at
_dyld_startwhen run from/Applications, while the identical bytes run fine from~/Applications. Shipping v0.1.2 into the cask does not fix that, and may reproduce it. Worth resolving #25 first, or at least checking whether v0.1.2 reproduces it before updating the cask.