Comment by sz4kerto | Hacker News Reader

Comment by sz4kerto | Hacker News Reader

Parent Full thread

I don't like semver.

If the library follows the rules, then...

Separation of minor and patch versions doesn't make sense. Both in the case of a minor or patch version change the client should be able to upgrade to the latest version.

A major version change means that backwards compatibility is likely broken. In that case, we're actually talking about a new library.

Therefore you can just use a single integer as the version number, and if you break backwards compatibility, then you change the library name. If you had a library called MyLib with version 1.0.0, then you can just go with version 1 instead. In case of a patch (no functional change), you go to version 2, and all clients can immediately upgrade. Then if you add a new feature, but backwards compatibility is preserved, you can go with version 3, and all clients can immediately upgrade. If you break backwards compatibility, then you rename your library to MyLib2, so it's clear to everyone that this is a new library (with similar functionality).

The real reason for minor and patch versions is that libraries actually don't follow semver, and patch version change means 'small change, don't worry about re-testing', minor version change means 'not that small change, you should re-test' and major version change means 'we've very likely broken most dependencies'.

In real life, you need to re-test anyway.

> Separation of minor and patch versions doesn't make sense.

Yes, it does.

> Both in the case of a minor or patch version change the client should be able to upgrade to the latest version.

Yes, but if it's a minor version change then, as a developer, I also want to review the changelog for new features I should consider whether we should add backlog items for refactoring to take advantage of, while a patch doesn't create that need. There is more space for SemVer-aware tooling than “is this safe to update”, though that's obviously the most important single piece of information.

> The real reason for minor and patch versions is that libraries actually don't follow semver, and patch version change means 'small change, don't worry about re-testing'

No, you always worry about retesting because SemVer is a statement of API intent, but does not include a guarantee against bugs, including new or modified bugs.

> No, you always worry about retesting because SemVer is a statement of API intent, but does not include a guarantee against bugs, including new or modified bugs.

That's what I do, yes. What I tried to explain is how library devs generally update versions.

> Yes, but if it's a minor version change then, as a developer, I also want to review the changelog for new features I should consider whether we should add backlog items for refactoring to take advantage of, while a patch doesn't create that need

This sounds like a good argument; although in my professional experience I found that 1) I need to re-test anyway 2) I need to read the change description anyway (as bugfixes most of the time mean behavioral changes, so I want to understand why the patch was necessary).

So overall I understand the theoretical argument behind semver, but I still don't see a very strong argument behind it. At least not as strong argument as popular semver has become.

> Yes, it does.

Collecting evidence for bold claim is left as an exercise to the reader.

To make things worse: sub one-point-zero versions don't actually need to mean anything, i.e. 0.0.1 -> 0.0.2 could be a breaking change as far as the semver spec is concerned. Library authors often stay in 0.x ranges "just in case the API needs to change".

And before anyone claims one shouldn't use stuff on versions below 1.0, consider that very popular projects like React were widely deployed in production before they decided to bump themselves out of 0.x...

This is reminiscent of gmail staying in "beta" for 5 years and having acquired 10 million users.

> And before anyone claims one shouldn't use stuff on versions below 1.0, consider that very popular projects like React were widely deployed in production before they decided to bump themselves out of 0.x...

I agree.

It's pretty easy to advise people not to use library with low version numbers, but then what do you use instead? Not every ecosystem out there has libraries for all common task, and if you need to, say, fill out a PDF form in language $X, and your choice is either a v0.5.22 library or writing it from scratch, I know I'd go for the v0.5.22... (especially with deadlines looming, and me having other things to do than reinvent the wheel).

> To make things worse: sub one-point-zero versions don't actually need to mean anything.

I think SemVer would be improved if 0.x versions were treated exactly like 1.0+ versions except that all minor versions had the semantic guarantees (none, that is) of major versions (but patches still had patch semantics.)

> Library authors often stay in 0.x ranges "just in case the API needs to change".

It's a problem that library authors don't want to commit to API stability and clearly differentiating breaking changes, but it's not a problem with SemVer that it makes it easy for them to notify of this intent in an unambiguous manner.

Reply on news.ycombinator.com