Yes. I meant that more as "Homebrew has undergone significant development changes since the creator of tea was last involved." In particular, the transition to the current architecture (favoring bottles over source builds on clients) happened well after him.
Edit: One of the reasons why I think it's important to continue to clarify this is because tea's repository description contains "brew2," implying a successor relationship.
Homebrew's kind of a dumpster fire now tho. The whole "you don't ever get to use an old version" thing was when I jumped ship. The fact that it can't handle two architectures in one install is also a big problem, though can be generally worked around
Homebrew is almost entirely beholden to the behavior of an operating system (and entire hardware ecosystem) that we have no say over. It also was simply never meant to be a versioned package manager, because the majority of its users (developers) want rolling updates for their tooling.
You want different things than Homebrew was designed to do, which is perfectly fine. But we make those constraints abundantly clear in our documentation, and they produce a vastly better user experience for 99% of our users.
Let me start by saying Homebrew is incredibly valuable and useful.
That said, the insistence on everything updating all the time is very frustrating. Being stuck waiting 30 seconds when trying to install something because brew is updating despite no one asking it to, random things breaking after an update, and needing to find escape hatches so an older version of some package can be installed are all pretty painful.
I think I've answered the part about why we do bleeding edge updates below, but for the auto-updating and upgrading behavior: you can set `HOMEBREW_NO_AUTO_UPDATE=1` and `HOMEBREW_NO_INSTALL_UPGRADE=1` in your shell environment. The former will prevent silent updates of the taps, and the latter will prevent unrequested upgrades of outdated formulae (per tap state).
Homebrew is just git under the hood, so upgrading an arbitrarily old core and tap state to the latest release may not result in a correct migration. That’s arguably more surprising, since a user then has to contend with broken package state instead of the occasional inconvenience of an auto-upgrade.
My issue is installing a package. Brew has a local state of the universe. It could just install the new package I ask for. Instead it installs the package plus updates for other packages I have installed. More than once I've had those unrequested updates break. Then I'm stuck yak shaving trying to fix some random package because I dared to install a new one.
I really appreciate the work all the Homebrew developers do. But I've lost a lot of time chasing down problems caused just because I installed some stupid utility.
>the majority of its users (developers) want rolling updates for their tooling.
I haven't met a single software developer who wants this. That's not to say your statement is incorrect -- I have no evidence stating otherwise -- but the idea boggles my mind.
A huge amount of Linux users use rolling release distributions now (Arch, Manjaro, EndeavourOS, etc). I prefer it as well because I find it less disruptive than occasional big-bang versioned releases.
Where versioning matters, we have better tools than OS package managers now (ex Docker).
I'd much prefer a compromise, like the FreeBSD quarterly updates vs daily, so you can pick the update frequency.
I can't tell you the total number of wasted hours my previous organisation spent upon maintaining MacOS infrastructure after random breakage due to homebrew, but it was a regular occurrence and likely a few hundreds of hours per year for the small setup we looked after, mainly for CI.
I am also in the camp of engineers who prefer stability over bleeding edge. But I do understand folks who prefer the latter modality. If dependencies are gonna break, often its more desirable to have them break quickly with a short remedial cadence to follow. In my own anecdotal experience though, "short" is probably too charitable of a descriptor for the time to fix.
>Incremental pain, delivered early, is both corrective and less expensive over the long run. If you need to remain version-locked for a specific reason, that reason is likely to be locally scoped rather than global, in which case TFA describes an attempt to address your problem.
This rests on the assumption of a relatively homogenized software development industry without any consideration for, at least, critical systems building. There's a broad range of disciplines in this industry which do not -- and cannot -- adhere to the practices you mention.
At my company, Homebrew is the de facto package manager for Mac. My team doesn't prefer constant rolling updates, but we do work around them. Have you polled users in any way to be sure that 99% of them consider this a feature, and not an issue they have to deal with?
It's based on our historical experience maintaining versions (or, at minimum, trying to not change the core DSL such that older formulae continue to work): we get an order of magnitude more requests for updates than requests for older versions, and even fewer specific complaints about breakage.
When a particular package (or version) is widely adopted and difficult to migrate away from (like versions of LLVM, Postgres, or Python), we provide `@`-discriminated versions to allow people to migrate at their own pace. If there's a particular formula you want versioned that we don't currently, please open an issue so that we can discuss it!
Rolling updates are the #1 source of "I don't understand why this isn't working anymore, it worked just fine yesterday!" and annoyances when you need a specific package version (n-2) to align with your deployment environment and Homebrew keeps updating to the bleeding edge.
(Beggars can't be choosers, etc. — I recognize the utility that Homebrew has provided to millions of people, that doesn't mean I can't mention its problems.)
Homebrew distrbutes recipes and bottles for older versions of many packages: postgres and node come to mind. And it's easy to maintain your own recipe if you need a different one.
