Why we’re switching to calendar versioning

Re:Why we’re switching to calendar versioning by stonogo on Sunday April 14, 2019 @01:21PM (#19660531)

You should be reading it as "the problem with semver is that it does not solve the problem it purports to solve."

An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest than ineffective rigor.

[ Parent | on HN ]

Re:Why we’re switching to calendar versioning by eikenberry on Sunday April 14, 2019 @03:29PM (#19661187)

Are you saying that knowing that there is an 80% starting chance of it not breaking anything is not any better not knowing that? That knowing that the devs don't think anything will break or not is worthless? And that is not counting the times when they do bump the major version to tell you it will probably break something.

The 100% solution you imply as a strawman here doesn't exist and some information is better than no information. And no one said Semver means you don't test, it just guides you on the expected behavior of the new release.

[ Parent | on HN ]

Re:Why we’re switching to calendar versioning by fgonzag on Monday April 15, 2019 @01:22AM (#19663267)

> An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business."

Maybe if you deploy directly to production before any testing is done.

[ Parent | on HN ]

Re:Why we’re switching to calendar versioning by fwip on Sunday April 14, 2019 @03:17PM (#19661132)

An 80% solution means you have 80% fewer unexpected breakages.

[ Parent | on HN ]