MUST be incremented if any backwards incompatible changes are introduced to the public API. None of the items in your list are changes to the public api, except maybe the forth one about changing a type definition.
All of the changes that I've listed introduce backwards non-compatible changes, e.g.
dropping Node.js version support
While whatever I typed in the codebase may not change the API as it appears in the source code, the transpiled version of the code now includes API changes that are no longer incompatible with my program, i.e. If you were running a jay-keckel-app that depends on my package slonik@28.0.0 and upgraded to slonik@28.1.0 you would most certainly not expect that to break your app, and if dropping platform version is not considered a breaking change, then it most certainly will. It is that simple.
To use conventional commits terms, it is a build type change, not an api type change.
This would be true only if JavaScript was a compiled language.
Tests aren't part of the public api
They are part of the contract that guarantees the integrity of the API, i.e. If tests are not passing on the platform for which the package was released originally, that's a breaking change.
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API
FYI, we are not the first to have this debate. There is a long, ongoing debate in the semver repository on exactly this subject.
All of the changes that I've listed introduce backwards non-compatible changes
Sure, but they don't all introduce public api changes and that's the point, semver only speaks to the public api.
While whatever I typed in the codebase may not change the API as it appears in the source code, the transpiled version of the code now includes API changes
Ah, as I said, node/javascript ecosystem is not my main area of expertise, so fair enough, my bad.
They are part of the contract that guarantees the integrity of the API
Ok, but that isn't the same thing as being part of the public api.
FYI, we are not the first to have this debate. There is a long, ongoing debate in the semver repository on exactly this subject.
Thanks for the link, it's an interesting debate, but it's ultimately moot. The spec says what the spec says and no where does the spec mention supported platforms being part of the public api, so it isn't part of the public api. Maybe that will change in semver 3.0.0, but as it stands, it is what it is or isn't what it isn't, as the case may be.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
All of the changes that I've listed introduce backwards non-compatible changes, e.g.
While whatever I typed in the codebase may not change the API as it appears in the source code, the transpiled version of the code now includes API changes that are no longer incompatible with my program, i.e. If you were running a
jay-keckel-appthat depends on my packageslonik@28.0.0and upgraded toslonik@28.1.0you would most certainly not expect that to break your app, and if dropping platform version is not considered a breaking change, then it most certainly will. It is that simple.This would be true only if JavaScript was a compiled language.
They are part of the contract that guarantees the integrity of the API, i.e. If tests are not passing on the platform for which the package was released originally, that's a breaking change.
FYI, we are not the first to have this debate. There is a long, ongoing debate in the semver repository on exactly this subject.
github.com/semver/semver/issues/716
Sure, but they don't all introduce public api changes and that's the point, semver only speaks to the public api.
Ah, as I said, node/javascript ecosystem is not my main area of expertise, so fair enough, my bad.
Ok, but that isn't the same thing as being part of the public api.
Thanks for the link, it's an interesting debate, but it's ultimately moot. The spec says what the spec says and no where does the spec mention supported platforms being part of the public api, so it isn't part of the public api. Maybe that will change in semver 3.0.0, but as it stands, it is what it is or isn't what it isn't, as the case may be.