Hacker News Reader

Comment by eurasiantiger | Hacker News Reader

Proper semantic versioning gives you certain guarantees.

Consider you’re on v1.2.1 of some package, pinned to your requirements as ”^1.2.1”.

A security issue gets fixed, v1.2.2 is released, your CI/CD can manage this upgrade automatically.

A new feature is introduced, v1.3.0 is released, your CI/CD can still manage this upgrade automatically. Developers know that there are new features because the minor version was incremented.

But then, some core API refactoring is done to support new integrations, which happens to break backwards compatibility. Now, v2.0.0 is released, and it is obvious to developers that something major has changed. Your CI/CD does not do this upgrade automatically.

View on HN

we tried semantic versioning for some time, but gave up. It is still people writing the code - and people do mistakes. So even when something is released as a patch how do we know that it was a mistake and it should have been a minor or a major version. Or they introduced a bug that would break our system?

So in the end we would still end up not trusting it and rely on testing (hopefully as automatic as possible) before we could merge the upgrade.

In the end we just switched to using timestamp-based version numbers and just try to upgrade often enough so each incremental change is small. And try to have good automatic tests that can do most of the regression testing for us.

Miatakes happen but as an end user of a library I prefer having semantic versioning giving me a hint on where it is likely there is an API breakage and where there is unlikely to be one. I still use lock files, read release notes and test but knowing where things are likely to break saves me time.

Agreed.

And I definitely don't read release notes of all my dependencies, even indirect ones, every time I update any. I lock to major versions (and hope my dependencies do to for indirect dependencies), and only look at release notes if an update breaks a build.

Eh, I would contend that poorly done semver is still better than date (only) versioning. You can always have date and/or hash as part of the metadata string. As long as you are honest with your team, saying "these are a best-effort to follow semver" it's clear what you are doing. If you are sub-1.0 basically every release is a minor bump anyways.

If my CI says a patch release broke my build, I think "I should figure out why, and report the bug unless it's already reported. This is a debugging task. If I can find time to do it now, it would be contributing back upstream."

If my CI says a major release broke my build, I think "OK, I will put this aside and schedule time to deal with it based on how important it is to upgrade, maybe I'll take a peak at the release notes (breaking changes section) now to get a sense of what might have broken and how much work it might be." And reporting a bug upstream is unlikely to be part of the work.

It's important signalling that helps us all cooperate to produce stable software, not just our own software, but the open source ecosystem we (in the best case) cooperatively develop.

It's also just about the only sane way to manage indirect dependencies that might be depended upon by multiple activated things. Widget and Doodad are both used by my project, and both depend on Button. How do we figure out what version(s) of Button will be (are intended to be, sans bugs) compatible with both of them?

Reply on news.ycombinator.com