This is a case of the Semantic Versioning doing the job it was designed for.
The 1.3.0 release just broke some poor regex I had written, since url.resolve now returns a trailing slash. Since it's a commonly used function, I have a feeling it might break a few apps out there. You shouldn't be making that kind of change in a PATCH number update. Hence the MINOR number update, perhaps.
That's semver doing the job people wish it were designed for, not semver doing the job it was designed for.
If it broke actual user code, then it MUST be a major version bump: "Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version." The idea with semver is that you can ask for 1.2.0 or any greater 1.x.y, and your app will still work. This was broken.
Maybe there's an argument that the break didn't matter that much, but it's still a spec violation. Which is why you get a bunch of annoyed people who care deeply about ABI compatibility, when asked to switch to semver, saying, "Do you really want me to release version 172.0.0?" If the rule is, bump major versions when the project maintainers think it matters, bump minor versions when they think it matters less, bump patch versions when they're pretty sure it doesn't matter, that's exactly what gets derided as "Sentimental Versioning" (http://sentimentalversioning.org/), just dressed up as semver, which is more harmful.
If you've got to pay attention to every release's changelog and run regression tests anyway, just in case the package maintainers disagree about what's important enough for a major version bump, then you have version lock problems anyway. If semver is just guidelines and not a spec, then it should make that clear.
There's nothing in the semver spec that allows bumping just the minor version for a backwards-incompatible API change because a change was a bugfix. The rules are:
> increment the MAJOR version when you make incompatible API changes,
> MINOR version when you add functionality in a backwards-compatible manner, and
> PATCH version when you make backwards-compatible bug fixes.
Minor versions aren't for less-important API breaks. They're for new functionality. If it breaks API, it's a major version; if not, it's a patch.
It is to semver's credit that it doesn't allow the maintainer any discretion here; many communities (like the Linux kernel community) have learned through experience that determining whether something is "just" a bugfix is impossible. Google for 'don't break userspace' and you'll find Linus flaming people for changing which error code gets returned from certain operations. Semver's rule is backwards-compatibility, which is a bright line: if the bug was that an interface didn't work at all in some or all cases, or it returned unusable results, then that failure is not part of the API and it can be fixed. If it caused something to have worked differently, in ways that people could have written software to assume the "wrong" but workable behavior, then it's part of the API.
It is not to semver's credit that it doesn't define the terms "backwards-compatible" or "public API," but I think those terms have clear enough meanings in practice. In particular, anything documented and in use is part of the public API, even if the docs don't match the actual behavior.
If a project really wants to say "semver, but our docs define the API, not the implmentation", they can do that, assuming their docs are in fact thorough enough that you can write a correct program without having a copy of the implementation. But that's also getting really close to "semver, except when we don't feel like it"... which is probably what everyone does in practice.
If it's a change that breaks code using the API, shouldn't it be a major version - 2.0? If you update the minor version all your changes should be backwards compatible. If you can't run an existing program, that's not backwards compatible.
The 1.3.0 release just broke some poor regex I had written, since url.resolve now returns a trailing slash. Since it's a commonly used function, I have a feeling it might break a few apps out there. You shouldn't be making that kind of change in a PATCH number update. Hence the MINOR number update, perhaps.
EDIT: url.resolve not path.resolve.