FreeFlow currently ships as a DMG from GitHub Releases only. Adding Homebrew support would give people a one-command install and make FreeFlow scriptable in dotfiles and machine-setup repos.
I've opened a PR implementing the simplest version of this. But where the cask file lives is worth deciding deliberately, because moving it later breaks anyone who already tapped. Three options:
1. Cask in this repo, repo doubles as a tap (what the PR does)
brew tap zachlatta/freeflow https://github.com/zachlatta/freeflow
brew install --cask freeflow
- No new repo, no third-party review. Merge it and it works.
- Two-line install rather than one.
brew tap clones the entire repo. I measured 34.7 MB tapped, nearly all of it Resources/ (icons, demo.gif), to deliver a 28-line Ruby file. Not fatal, just wasteful.
2. Dedicated zachlatta/homebrew-freeflow tap
brew install --cask zachlatta/freeflow/freeflow
- Small clone, conventional layout, and no separate
brew tap step.
- Needs a new repo, and
release.yml would have to push to it with a token carrying cross-repo write access.
3. Official Homebrew/homebrew-cask
brew install --cask freeflow
- Best experience.
brew search freeflow finds it, and BrewTestBot auto-bumps the version through the livecheck block in the cask, so releases need no manual step at all.
- Notability is not a problem. Homebrew's policy asks for 30 forks / 30 watchers / 75 stars, or 90 / 90 / 225 for a self-submission by the repo owner. At ~2.3k stars and 217 forks this clears both, so it works whether you submit it or I do.
- The
freeflow token is currently unclaimed (nearest neighbours are feedflow and freeshow).
- Casks must be signed and notarized, which
release.yml already handles. I verified the published v1.2.0 DMG reports accepted / source=Notarized Developer ID and is stapled.
- Trade-off: Homebrew maintainers own the file, and bumps go through their queue instead of yours.
Suggestion
Option 1 now, option 3 as the destination.
The cask file is byte-identical between all three, so nothing is thrown away. Option 3 is literally copying Casks/freeflow.rb into a homebrew-cask PR. Once that lands, both the in-repo cask and the auto-bump step in release.yml can be deleted.
Happy to raise the homebrew-cask PR once you've merged and are happy with how it looks. If you'd rather skip straight to option 2 or 3, that's an easy change to the PR. Which direction do you prefer?
FreeFlow currently ships as a DMG from GitHub Releases only. Adding Homebrew support would give people a one-command install and make FreeFlow scriptable in dotfiles and machine-setup repos.
I've opened a PR implementing the simplest version of this. But where the cask file lives is worth deciding deliberately, because moving it later breaks anyone who already tapped. Three options:
1. Cask in this repo, repo doubles as a tap (what the PR does)
brew tapclones the entire repo. I measured 34.7 MB tapped, nearly all of itResources/(icons,demo.gif), to deliver a 28-line Ruby file. Not fatal, just wasteful.2. Dedicated
zachlatta/homebrew-freeflowtapbrew tapstep.release.ymlwould have to push to it with a token carrying cross-repo write access.3. Official
Homebrew/homebrew-caskbrew search freeflowfinds it, and BrewTestBot auto-bumps the version through thelivecheckblock in the cask, so releases need no manual step at all.freeflowtoken is currently unclaimed (nearest neighbours arefeedflowandfreeshow).release.ymlalready handles. I verified the published v1.2.0 DMG reportsaccepted / source=Notarized Developer IDand is stapled.Suggestion
Option 1 now, option 3 as the destination.
The cask file is byte-identical between all three, so nothing is thrown away. Option 3 is literally copying
Casks/freeflow.rbinto a homebrew-cask PR. Once that lands, both the in-repo cask and the auto-bump step inrelease.ymlcan be deleted.Happy to raise the homebrew-cask PR once you've merged and are happy with how it looks. If you'd rather skip straight to option 2 or 3, that's an easy change to the PR. Which direction do you prefer?