Side-topic: Shouldn't the breaking changes be enough reason to bump the version to 2.0?
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.
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.
Only in the Homebrew backwards-day world is having globally installed software not owned by root "frowned upon".