6 ms·

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

by sugarraps 10y ago

jzamora 10y ago
Yes, it should. But that scares people.
yes_or_gnome 10y ago
Not really. Signatures should be SHA256 already, you shouldn't be running as root (which as always been frowned upon).
- stephenr 10y ago
  > which as always been frowned upon Only in the Homebrew backwards-day world is having globally installed software not owned by root "frowned upon".
  - matthewmacleod 10y ago
    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".
    - stephenr 10y ago
      What part of that UNIX education would cover putting user-owned binaries into /usr/local ?
      - dasil003 10y ago
        Well at least it's in /usr/local/Homebrew now...
thedaniel 10y ago
relevant discussion here https://github.com/Homebrew/homebrew-core/issues/6677 https://github.com/Homebrew/homebrew-core/issues/6677
- pflats 10y ago
  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.
  - jffry 10y ago
    > 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.
    - Touche 10y ago
      In this case it was documented.
    - pflats 10y ago
smackfu 10y ago
Unfortunately most people now consider major versions to indicate major feature additions rather than breaking changes.

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

jzamora 10y ago

Yes, it should. But that scares people.

yes_or_gnome 10y ago

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

stephenr 10y ago
> which as always been frowned upon Only in the Homebrew backwards-day world is having globally installed software not owned by root "frowned upon".
- matthewmacleod 10y ago
  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".
  - stephenr 10y ago
    What part of that UNIX education would cover putting user-owned binaries into /usr/local ?
    - dasil003 10y ago
      Well at least it's in /usr/local/Homebrew now...

thedaniel 10y ago

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

pflats 10y ago
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.
- jffry 10y ago
  > 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.
  - Touche 10y ago
    In this case it was documented.
  - pflats 10y ago

smackfu 10y ago

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