Homebrew tap for the macOS apps I publish under adamXbot.

One cask. This repository holds the package definition only — no build logic, no source.

The consumers are people running brew, not other repositories. Nothing else in the portfolio depends on this tap at build time, and no release workflow writes to it — BananaBlitz's release job attaches a DMG to its GitHub release and updates its Sparkle appcast, and stops there.

brew tap adamxbot/tap
brew install --cask bananablitz

The fully-qualified name works without tapping first, and stays unambiguous if a package of the same name ever appears in homebrew/cask:

brew install --cask adamxbot/tap/bananablitz

Upgrading is ordinary Homebrew:

brew update
brew upgrade

Cask updates arrive as pull requests, not direct pushes to main:

1. A release in the app's source repo — via the shared release workflow in privacykey/gh-workflows — renders the cask with the new version, download URL, and SHA-256, and opens a PR against this tap.
2. The Tap syntax check verifies that every cask and formula still parses and loads (ruby -c + brew readall).
3. A maintainer reviews and merges. brew update && brew upgrade --cask <name> then picks up the new version.

Manual bumps follow the same path: edit the cask on a branch and open a PR.

To remove the app and the tap:

brew uninstall --cask bananablitz
brew untap adamxbot/tap

The cask runs a postflight that strips com.apple.quarantine from the installed bundle, and its caveats print the same command in case macOS still reports the app as damaged or from an unidentified developer:

xattr -cr /Applications/BananaBlitz.app

This repository has no releases and no tags, so there is no tap version to pin against. brew tap tracks the default branch: whatever is on main is what every tap user resolves on their next brew update.

Versions are per-package instead. Casks/bananablitz.rb pins an exact version and sha256 against a release asset in the BananaBlitz repository. There is no livecheck block and no automation that opens bump pull requests here, so a version bump is a hand edit.

That gap is live right now: the cask pins 0.0.2, while the most recent BananaBlitz release is v0.0.3, from April 2026. Anyone installing from this tap today gets 0.0.2. Closing that gap is a separate change, not something this README papers over.

If you need to hold whatever you have installed, brew pin bananablitz freezes it against brew upgrade.

main is covered by an active ruleset that requires a pull request and blocks force-pushes and deletion, so nothing lands directly. That matters because the blast radius of a bad merge is every tap user: a cask that fails to parse breaks brew update for anyone who has this tap installed, not only the people who installed the package.

Check a change before you merge it:

ruby -c Casks/bananablitz.rb        # parses?
brew readall adamxbot/tap           # loads? (needs the tap installed)

To bump a version by hand, take the sha256 from the new release asset rather than trusting the release notes:

curl -sL https://github.com/adamXbot/BananaBlitz/releases/download/vX.Y.Z/BananaBlitz.dmg | shasum -a 256

There is no CI on main today. A syntax gate that runs ruby -c and brew readall on pull requests is proposed in #1 and has not been merged.

Long stretches with no commits are normally fine for a tap — a cask that still matches its upstream release needs no attention. That is not the situation here: bananablitz.rb is behind, so anyone installing from this tap today gets an older build than the latest release. The thing to watch is the version drift above, not the commit date.