Automatic cleanup sounds like a major improvement. It's almost scary how much disk space is used by Brew if you don't/didn't run cleanup periodically.<p>Since I don't install 'mission critical' application through brew, I've always had the following command run daily though a cronjob:<p><pre><code> brew update && brew upgrade && brew cleanup</code></pre>
I really wish these release notes would explain what is going on for people who don't know the internals of homebrew. Especially since homebrew force-updates itself and there's no way for users to avoid these changes.[1]<p>There are several updates in here that make me worry that this is somehow going to break my environment or otherwise bite me in the ass when I do something innocent like install Ghostscript and find that Emacs no longer works and to figure out how to fix it's going to be hours of reading github issues. Which is an experience I've had before, repeatedly.<p>"brew update no longer migrates legacy keg symlinks, tap names, repository locations, cache locations or cache entries."<p>Is this going to break something I installed years ago? Maybe the homebrew maintainers know, but average tool users don't.<p>"Homebrew/homebrew-core requires all formulae to be open source by the OSI definition."<p>Does this mean that something I used homebrew to install in a previous version will no longer be getting updates? Will things that depend on it still be getting updates? Does whether or not updates happen depend on some random committer's legalistic interpretation of an open source definition? Why exactly is this kind of purist decision being imposed on users?<p>[in 2.0]
"brew cleanup will be run periodically and for trigger individual formula cleanup on reinstall, install or upgrade. You can enable this behaviour now on 1.9.0 by setting the HOMEBREW_INSTALL_CLEANUP variable."<p>So you're going to periodically make maintenance changes to my system without my permission. Goodie.<p>Someone really needs to write a guide to migrating away from homebrew for people in the unfortunate situation of having used this tool for a long time, and find it taking more and more liberties with one's computer, but also having numerous essential packages now managed by it and not sure how to move to alternatives without weeks of breakage.<p>[1] <a href="https://paultopia.github.io/posts-output/anti-homebrew/" rel="nofollow">https://paultopia.github.io/posts-output/anti-homebrew/</a>
Good job! Homebrew is, at least for me, essential for using macOS as a true *nix, and most of the changes (implemented or proposed) seem good (e.g., the ability to automatically run cleanup)<p>I am a little bit worried for the removal of all options that is planned for the 2.0.0 version: I have some formulae installed from source (with additional options) and I like the flexibility that they give. Hopefully the migration to an "options-free" Homebrew will be smooth and some alternative when options are needed (not requiring a lot of third-party taps) will emerge.
Really not a fan of the removal of options, imo it is one of the greatest perks of homebrew. Can I manually build my own software? Yes. Do I want to have to maintain a tap for every single thing I want to use options on? No, I do not.<p>This move along with the python2 vs python3 change that was made previously has left a seriously sour taste in my mouth about Homebrew. I'm actively looking at other options.
> Homebrew 1.9.0 no longer runs on 32-bit Intel CPUs.<p>Where does this constraint come from? Homebrew is written in Ruby.<p>To cut down on compilation from source issues? Or Homebrew uses language features from Ruby versions greater than what Apple shipped in their latest 32-bit supported OSX versions (as homebrew insists on using the system default binaries)?
Windows support! That's a surprise.<p>Chocolatey is... ok. It works, mostly, but it's a common occurrence for upgrades to fail because the package maintainer forgot to update the hash, or the program's built-in autoupdater already ran and moved things around, or a phantom .install dependency is missing, or some other inscrutable problem. Competition will be good for it (and the developer sells a premium version, so I do expect proper competition). All the other package management tools on windows have fairly tiny repositories and are, as far as I can tell, optimized for the workflow of sysadmins building images.<p>I wonder if Brew has any plans to support that package management framework Microsoft is apparently still working on? (<a href="https://github.com/OneGet/oneget" rel="nofollow">https://github.com/OneGet/oneget</a>)
Remember that Homebrew by default records some of your usage data via Google Analytics. Disable that if you are not comfortable, or switch to MacPorts.
It's a bit weird how they're announcing a new mission statement about how this is a small focused project for macOS at the same time they're announcing Windows and Linux compatibility.
Is it me or homebrew became slower recently?<p>I recall that some commands where much faster. It takes on average 2.5 seconds to do brew search.<p>$ time brew search mpv
==> Formulae
mpv<p>==> Casks
mpv
brew search mpv 2.34s user 0.59s system 67% cpu 4.348 total<p>This is not autoupdate — this is with set HOMEBREW_AUTO_UPDATE_SECS to 14400.