4 ms·

I would recommend, as a general practice in any language, to never assume that version numbers signify anything other than chronological order. Apply the same l

I would recommend, as a general practice in any language, to never assume that version numbers signify anything other than chronological order. Apply the same level of caution and verification to upgrading a dependency from 5.1.1 to 5.1.2 as you would when upgrading from 5.1.1 to 6.0.0. People are inconsistent with semantic versioning, so it can't be trusted. Even people who have been consistent with it in the past may behave differently in the future. I've been burned too many times and I won't even do minor version upgrades anymore unless I have 100% test coverage on the parts of my code that use the dependency.

oweiler 9y ago
That's why for internal projects we switched to using the build number for versioning. Developers rarely get SemVer right, or outright don't care about it. We've also seen patch versions breaking clients because of some transitive dependency upgrade which was impossible to forsee.
- bunderbunder 9y ago
  Ideally you shouldn't be changing dependency versions when you're just doing a patch, precisely because it's so hard to predict potential impact when you upgrade a dependency.
  - marcodave 9y ago
    > Ideally you shouldn't be changing dependency versions when you're just doing a patch, what if the patch included updating the (patch) version of a direct dependency? then you don't have much more control over what that direct dependency would bring on