SemVer has failed us

In languages where that difference matters, let's say Java/Scala [1], there are way too many possibilities:

- bug fix: forward and backward binary compatible; basically a drop-in replacement. Package managers are supposed to resolve conflicts between those automatically,

- new feature, but backward binary compatible; just some new code alongside the old. Package managers should also be able to resolve a conflict between dependencies that depend on different versions of those.

- bug fix: forward and backward source compatible; here we have a problem: we can guarantee developers that they won't have to edit a single line of code to migrate, but we can't allow (binary) package managers to do anything. They have to rebuild their library, which means bumping their own version number. And does that means that their new version becomes binary-incompatible with the previous one, or just their dependencies?... who knows? Maybe it depends on if the consumer of that library calls into the conflicting dependency directly or only uses it indirectly? Maybe not? Can we tell?

- new feature, backward source compatibility, but no binary compatibility; same as above: package managers cannot do anything, and conflicting transitive dependencies on the new and the old may or may not be solved by recompiling one's library. The only safe bet is to wait for the dependencies to upgrade.

- all bets are off (possibly split in minor and major): here at least we know there is nothing to be hoped. But in practice after upgrading to the new API, you are faced with the same questions concerning that thing's dependencies...

And if every dependency manager within the same packaging eco-system doesn't enforce a single global versioning scheme, how can they handle any dependency version conflict anyway? They could if packages could auto-describe their semantic versioning, so basically they can't, so they don't, and we're back to source dependencies, with recompile and bump in version number for every dependency change (ok, sometimes they do try and we get JAR hell...). And since a single versioning scheme isn't enforced, people use hundreds of different ones (or just none), and the maintainer of a library has to make all of those decisions, recursively (except that below 1 level of dependency, he/she might not be able to do anything as long as even a single dependency keeps an old conflicting dependency around, but they still have to check, in case they are lucky and can do something), taking into account the different versioning semantics of each dependency. That's madness.

So in the end, if we get a conflict between dependencies far down in the dependency tree, it becomes something pretty ugly:

- if guaranteed binary compatibility, everything is fine,

- otherwise:

0) look at that dependency's official versioning scheme, usually find nothing (except for big famous libraries)

1) pick the highest common-one, try to recompile your library

2) if it works, try the tests (your library's tests, not your dependencies' tests, mind you. Even though those should probably be run, considering they directly depend on it, and use (and hopefully test) more stuff from that library)

3a) it it works, ship it and pray.

3b) it will probably fail somewhere since the dependencies in between have not be recompiled; then you can only wait for them to upgrade.

I know in the end this doesn't work so bad (well, everything is relative...), but it still makes me sad that upgrading dependencies is still human-based trial and error.

Oh. I guess this is a rant.

[1] that's just what I am the most familiar with, but you could say the same with C packages in a distro's package repo, for example.

[1]: http://pub.dartlang.org/

Semver is a way to communicate between people about compatibility expectations they should have between two versions of a package. When library maintainer says "this version changes from 1.2.3 to 1.3.0" that tells something useful to a human consumer of that package.

It absolutely does not communicate anything precise in the language of machines. It's not a formal system, and compatibility isn't formally defined. If you want it to be that, you're setting yourself up for hearthbreak.

Code reuse is a social process. Understand that semver is a tool at that level and you'll be pretty happy with it. In my mind, the most important feature of semver is that by associating pre-arranged semantics to versions, consumers can specify version ranges before those versions exist.

If I'm using foo 1.2.3, I can depend on foo >=1.2.3

    Part of the major issues with semver is that patchs could
    break. A feature could be "fixed", but a consumer could 
    have relied on that very buggy feature, and patching it 
    would break their app.

Being that rigorous isn't useful. Instead, realize that most patches don't break most users. For the ones that do, that's why you pin. You are pinning, aren't you?

    Versions 

    The current solution to the above problems is to pin all
    dependencies. However, this is absolutely stupid and 
    annoying to me. ... When every library pins, you're going 
    to have a lot of duplicate dependencies, even if they're 
    the same version!