3 ms·
That's the point. It's meaningless. If I'm a client, and I've bumped my dependency from 1.2.3 to 1.3.0, it doesn't matter in that moment whether my deployment i
by regularfry 6y ago
That's the point. It's meaningless. If I'm a client, and I've bumped my dependency from 1.2.3 to 1.3.0, it doesn't matter in that moment whether my deployment is on fire because there was an unannounced but intentional change, or a breakage because of a bug. Semver is supposed to give me confidence that that upgrade is safe, and it fundamentally can't.
- have_faith 6y agoBut it does prepare you for the scale of potential breakage? I always just saw semver as a scale of the possibility something could break without any guarantees. Major change is highly likely, minor change is potentially and patch is shouldn't but give it a quick check. That doesn't make it meaningless, it just makes it not black and white. No change no matter how small should give anyone confidence that something won't break. I don't think it reduces the value of semver though. It's just another attempt in a long line of attempts to categorise changes into something quickly digestible and it does that well enough.
- wolrah 6y ago> If I'm a client, and I've bumped my dependency from 1.2.3 to 1.3.0, it doesn't matter in that moment whether my deployment is on fire because there was an unannounced but intentional change, or a breakage because of a bug. So in your mind because bugs exist there is no purpose in communicating whether an update intentionally changes things? I can not see your logic. Bugs will always exist. No meaningfully complicated software will ever be bug free. By your logic we should just never upgrade anything? Except that there are time-based bugs all over the place, so not upgrading anything is also guaranteed to break things (2038 anyone?)