Hacker News new | ask | show | jobs
by sugarraps 3516 days ago
Side-topic: Shouldn't the breaking changes be enough reason to bump the version to 2.0?
4 comments

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.