3 ms·

> Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior ar

> Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. Actually it's pretty clear that they did their homework.

stouset 9y ago
If you count as “their homework” the dozens of iterations of this we’ve been through. First, it was literally argued that just `go get` just grabbing `master` of all of your dependencies was good enough, because if you ever need to release something backwards-incompatible, you should create a new repo. I wish I were making this up. Then we just vendored everything and never updated our dependencies, and that too was good enough. Then GoPM, go dep, and a deluge of other tools that I don’t care to track down or sort into their appropriate order. And now this, which decides to buck the trends that everyone else follows yet again and attempts to satisfy dependency trees by choosing the minimal compatible versions instead of the maximal ones, with the completely foreseeable consequences that: * security patches won’t be applied * issue trackers will be filled with bug reports that are closed with messages saying “this was fixed months ago, update”, and * updating dependencies will become *harder*, since this is a straightforward result of doing it less frequently
- mjevans 9y ago
  If you can't go get -u all on your project at least you have done something 'wrong' or your upstreams have done something wrong. First, the upstream behavior; not supporting the published interface (as it was and should therefore work forever) means they need to deprecate that interface and release another with the incompatible changes. However the PROPER way of handling this is to add new versions of exposed public methods and interfaces / constants with new names and only if such a major change is required that you can't support the old interfaces, at THAT point, release at least under a new inclusion path if not new dependency name. Things local a developer might have done wrong: A) include an 'immature' upstream repository that behaves like above. B) use non-public components or other unsafe practices to go beyond the interface contract that was exposed.
  - TheDong 9y ago
    I guess using any dependency, directly or transitively, that declares itself pre-1.0 in the go or semver meaning of the word, is thus right out. At that point, almost all of the go ecosystem can't be used.

stouset 9y ago

If you count as “their homework” the dozens of iterations of this we’ve been through. First, it was literally argued that just `go get` just grabbing `master` of all of your dependencies was good enough, because if you ever need to release something backwards-incompatible, you should create a new repo. I wish I were making this up. Then we just vendored everything and never updated our dependencies, and that too was good enough. Then GoPM, go dep, and a deluge of other tools that I don’t care to track down or sort into their appropriate order. And now this, which decides to buck the trends that everyone else follows yet again and attempts to satisfy dependency trees by choosing the minimal compatible versions instead of the maximal ones, with the completely foreseeable consequences that: * security patches won’t be applied * issue trackers will be filled with bug reports that are closed with messages saying “this was fixed months ago, update”, and * updating dependencies will become *harder*, since this is a straightforward result of doing it less frequently

mjevans 9y ago
If you can't go get -u all on your project at least you have done something 'wrong' or your upstreams have done something wrong. First, the upstream behavior; not supporting the published interface (as it was and should therefore work forever) means they need to deprecate that interface and release another with the incompatible changes. However the PROPER way of handling this is to add new versions of exposed public methods and interfaces / constants with new names and only if such a major change is required that you can't support the old interfaces, at THAT point, release at least under a new inclusion path if not new dependency name. Things local a developer might have done wrong: A) include an 'immature' upstream repository that behaves like above. B) use non-public components or other unsafe practices to go beyond the interface contract that was exposed.
- TheDong 9y ago
  I guess using any dependency, directly or transitively, that declares itself pre-1.0 in the go or semver meaning of the word, is thus right out. At that point, almost all of the go ecosystem can't be used.