3 ms·
I would say that I would confidently update from: "1.2.1" -> "1.2.6" without batting an eyelash if my tests passed. "1.2.1" -> "1.6.2" would give me pause, but
by lolsal 6y ago
I would say that I would confidently update from: "1.2.1" -> "1.2.6" without batting an eyelash if my tests passed. "1.2.1" -> "1.6.2" would give me pause, but I wouldn't shy away from it.
Going from "2020.05.04 => 2020.06.20" doesn't tell me _anything what so ever_ about backwards compatibility or risk that I'm taking on. Is that the equivalent of going from "1.x to "2.x" or "1.x" to "8.x"? Who knows.
- lillesvin 6y agoAs I said, from my perspective they're useful for different purposes. I've worked on software (internal sales system) that the end-users were interacting directly with. They'd always be running the latest version and thus versioning by dates would have been a lot more tangible to them. Over the course of 5 years and several thousand bug reports from end-users and 2nd/3rd line support I've never once seen a bug report that mentioned a version number. It was always "the version that was deployed last week" or something to that effect despite the version number being visible in the app at all times. For APIs and libraries semver makes a lot of sense, I agree, but not all code is APIs or libraries.