Hi Mike, I’m @bfontaine on GitHub (I helped maintain Homebrew in ~2014-2016). I’m always impressed at your longevity as a maintainer; it’s been like what, 16+ years you’ve been maintaining Homebrew and you’re still here, still shipping new features! Thank you for everything!

I have switched my full OS-level dev env to https://mise.jdx.dev/ from Homebrew+pipx+npm, initially as an experiment but found out that it actually works amazingly well. Many things get installed directly from GitHub releases or a corresponding package manager (uv, pnpm, go get ...), zero glue code to "repackage", zero version lag. You can install any arbitrary version of a package, even multiple ones at once, and dynamically adjust which ones are active per working folder or explicitly through environments.

Funnily Mise does not support dependencies, and I was quite surprised that it mostly doesn't matter, as either pnpm/uv handles that, or it's a static binary that just works. In the past, had the unfortunate experience of packaging a Python application for Homebrew (the ridiculous process involved importing around 50 dependencies as "resources", building every single one from source or manually checking if it's already on Homebrew, declaring build toolchains for 5 different programming languages as dependencies, waiting over an hour for CI to finish on every update, then an upstream update introduced a "build-time dependency loop" and the project suddenly became unpackable for Homebrew) so I totally get why Mise took the "easy way out" and just relies on language-specific package managers directly.

Only thing from my Brewfile that I couldn't replace was the Docker CLI (needed to interact with Colima). And I still use Homebrew for casks. I encourage others to experiment with their dev setups, there are some amazing new tools out there.

Thanks for all the hard work.

We are not many [1], but Homebrew has been a great way to quickly bootstrap an environment in immutable Linux distributions.

Note that certain operating systems such as Universal Blue's Bazzite (1.28%), Bluefin (0.49%) and Aurora (0.28%) default to bundling Homebrew [2].

[1] https://formulae.brew.sh/analytics/os-version/365d/

[2] https://github.com/ublue-os/brew

Could really use a good rollback mechanism, is there one in the works perchance? I have broken my home server multiple times with bad InfluxDB and Grafana updates, and rollback was a huge pain. I’ve now disabled cleanup so old versions of packages are kept, but there must be a better way.

Thanks for the update. Is there any chance we can get some kind of cooldown mechanism in Homebrew?

The only people I want to trust to quickly ship new code to my machine are Apple and my browser (which handles more untrusted input than anything else).

For everything else (vscode and its extensions, npm, homebrew, and all the apps that self-update), I prefer to err on the side of waiting a few days.

Some exceptional 0days might warrant a cooldown bypass, but even in its current form users are vulnerable to 0days until they run brew upgrade.

    Bundler
    RubyGems livecheck
    npm and pip defaults
    PyPI resource resolution
    npm and PyPI in bump

The deprecation of Intel support is agressive! Every Mac enthusiast I know who uses a Mac as a server uses their old machines, which are pretty much all Intel. We'll lose support from you guys a year before Apple!

I know supporting Intel is an ordeal and a choice, but I'm firmly on the camp that Homebrew should find a way to maintain Intel support as long as possible.

I know this runs on Linux too. As a Linux user, I'm unclear on why I might use this instead of apt or dnf, for example. Any Linux users out there have experience with both Homebrew and one of these?

Is it true that contributors to homebrew need to know how to invert a binary tree?

Congrats on the performance improvements. That's the most pleasant `brew upgrade` session I've had in years

I assume this trust issue is related to the not-infrequent MacOS notifications asking for permission to run Ruby in the background or when the machine starts. It says nothing about Homebrew though.

Awesome! Thank you for the update.

I noticed that homebrew updated _all_ my casks when running 'brew upgrade' (even those with "auto_updates: true" in their Cask JSON API).

Is this intended, new default behavior? This did not use to happen...

Thanks for producing such an amazing piece of software. Most of my Mac installations are based on Homebrew, but I have to rely on version management tools like Pyenv or nvm for Python and Node. Wish there was some standard 'Homebrew' way to install multiple versions of node, php and Python

Is there a way to `brew trust` inside my Brewfile? That'd be nice for the handful of formulas I install from github repos via `brew bundle --global`.

Personally I stopped using Homebrew after I got screwed too many times on mandatory upgrades that I couldn't pin. I use a combination of Mise and MacPorts now so I don't get any more surprise breakage and forced obsolescence. Plus Mise allows me to upgrade to any new version, whereas with Homebrew you have to wait for whenever the tap feels like upgrading (llama.cpp tap skips every 10 releases)

Interesting that the `brew-rs` experiment has concluded and didn't find much of a performance increase. I suppose that is expected though with a lot of the bottleneck being network IO?

Is the eventual goal to move most formula/cask behavior into declarative install steps and treat Ruby as an escape hatch?

Does Homebrew have good support for exact (and older) versions of packages now?

Thanks for the hardwork.

homebrew is so nice, thank you for all your effort

Hell yeah, tap trust!!!

Does homebrew still do that insane thing when you want to upgrade a single package it tell you "hold my beer" and starts installing postgres and some obscure python version?

[dead]

[dead]