4 ms·
Dismissive comments like this make me not want to read HN anymore and in addition it’s against the HN guidelines: It’s snarky. It’s incurious. It’s neither tho
by js2 4y ago
Dismissive comments like this make me not want to read HN anymore and in addition it’s against the HN guidelines:
It’s snarky. It’s incurious. It’s neither thoughtful nor substantive. It’s flame bait. It’s a shallow dismissal. It doesn’t teach anything. It’s the most provocative thing to complain about.
https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
I’m sorry I had to leave this comment, so let me also try to respond thoughtfully:
Assuming that PyTorch is using semantic versioning requires that the major version MUST change when making a backwards incompatible API change:
> Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.
This requirement does NOT preclude changing the major version when making backwards-compatible changes.
PyTorch has not violated semver here. It is absolutely compatible with semver to bump the major version for marketing reasons.
https://semver.org/ https://semver.org/
- lostmsu 4y agoFrankly, they are not really showing benchmarks, and given my experience with hyped torch.jit I don't expect much.
- belval 4y agoPersonal attack aside, from your own link: > Given a version number MAJOR.MINOR.PATCH, increment the: > MAJOR version when you make incompatible API changes > MINOR version when you add functionality in a backwards compatible manner > PATCH version when you make backwards compatible bug fixes > Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. You can point towards some other details, but it doesn't change the fact that for the overwhelming majority of people, the quote above is what semver is. Besides, my original comment does not say "They broke semver", it says they shouldn't bump the major version if they don't make backward incompatible change because afterwards the mental model of "Can I use version X.Y.Z?" is broken. When TensorFlow moved to 2.0 it's because they were changing from graphs and session definition to eager mode. That makes sense, that means the underlying API and how the downstream users interact with it changed. These are just newer features that, while very useful, have limited bearing on downstream users.