Side-topic: Shouldn't the breaking changes be enough reason to bump the version to 2.0?

relevant discussion here https://github.com/Homebrew/homebrew-core/issues/6677

Of specific interest: "This deprecation was announced and these methods removed/undocumented before 1.0.0 was tagged so arguably it was not part of the public API when 1.0.0 shipped."

I'm ambivalent. If I rev 1.0 - 1.1, then I'm going to assume the API won't change, even if I'm using undocumented and warning-spitting methods.

But I shouldn't be doing that, I shouldn't roll in a minor update without at least reading the change log, it's a FOSS project run by a volunteer staff, and brew never swore an oath to follow the laws of versioning as set by semver.org.

If the brew documentation said, "We use semantic versioning," then I'd say the complainants were correct. Otherwise, versions are just versions, and all you can count on is (Major Changes).(Medium Changes).(Minor Changes).(Tiny Changes).(etc.)

edit: Thoughts:

Years and years ago, I spent a lot of time and energy ranting about the fact that Google called GMail "beta software" when it was clearly not feature complete, and beta has a meaning, and we are just destroying a useful system of names for the software testing and release cycle, and…

But in the end, version numbers and development stages are language, and you cannot force your language on others, irregardless of whether or not you'd like to.

> I'm going to assume the API won't change, even if > I'm using undocumented and warning-spitting methods.

And here I disagree, quite strongly. If I'm using "undocumented and warning-spitting methods" then I know what I have done is a hack and those methods could disappear or change at any time and I should proceed at my own peril.

>And here I disagree, quite strongly. If I'm using "undocumented and warning-spitting methods" then I know what I have done is a hack and those methods could disappear or change at any time and I should proceed at my own peril.

We're in complete agreement, actually. I'm just saying that I generally don't expect things like that to change on a point release, not that it can't, won't, or shouldn't. You're definitely juggling chainsaws if you're in a situation like that.

In this case it was documented.

Yes, it should. But that scares people.

Not really. Signatures should be SHA256 already, you shouldn't be running as root (which as always been frowned upon).

> which as always been frowned upon

Only in the Homebrew backwards-day world is having globally installed software not owned by root "frowned upon".

Hmmm. The UNIX education that's been hammered into me since childhood has said "If you can do it as not-root, don't do it as root".

What part of that UNIX education would cover putting user-owned binaries into /usr/local ?

Well at least it's in /usr/local/Homebrew now...

Unfortunately most people now consider major versions to indicate major feature additions rather than breaking changes.

> Disable running Homebrew as the root user (e.g. sudo brew)

why? Just curious, because I always use macports with sudo.

We don't drop privileges when building (as we're not designed to run as root) and the macOS sandbox has issues with the root user so unfortunately you're giving every package you install root access to write to (almost) anywhere on your system. This is bad so we've stopped it.

> We don't drop privileges when building

So why did you choose to disable running as root altogether rather than dropping privileges when building?

Using the root user like this is used by a tiny minority of our users. The deprecation notice noted we'd happily accept a PR that implemented the privilege dropping but one never came. In a world where Homebrew is run by a full-time, paid staff we'd likely have implemented it but there's too much other, more important stuff that needs done by our understaffed team.

I assume it's because 1) it's not really needed, and 2) it prevents shady packages from executing scripts as root.

IIRC because it could cause problems with overwriting system libraries in earlier versions, so it has long been deprecated.