
“It’s not a bug, it’s a feature” – The problem with SemVer - jondubois
https://medium.com/@jonathangrosdubois/its-not-a-bug-it-s-a-feature-the-problem-with-semver-cb067de7843c
======
radarsat1
> Sometimes you need to use your understanding of the project and the
> ecosystem to make informed probabilistic decisions when it comes to
> versioning.

ie. your knowledge of the API's semantics. Hence, semantic versioning. Mystery
solved?

~~~
CaliforniaKarl
I personally don't think so. As the author mentions, it's possible (rightly or
not) for developers to use some upstream behavior that ends up being
classified as a bug. Then what appears as a bugfix actually causes a breakage,
which (I believe) is what Semantic Versioning is supposed to help prevent.

I think that's one of the reasons why Packager Versioning can be useful: The
packager picks an upstream release, forming the base of the package version
(for example, "12.2.2"), and appends an indicator that this is the first
release of the package (so now we have "12.2.2-1"). Increasing that last
number means updating the packager's changelog with an explanation of which
fixes were cherry picked, and what other changes are done.

There's also capability for derivative packagers to add their own information,
and for testing/backports packages that are lower-priority than the more
"official" ones.

So, although Semantic Versioning is fine, I still like having packager version
numbers!

