2 ms·
Not if they don't actually change the API. If you fix an internal server bug that relates to a visible change in the API, then yes, it's a patch in the semver.
by rswail 6y ago
Not if they don't actually change the API. If you fix an internal server bug that relates to a visible change in the API, then yes, it's a patch in the semver.
If you change something internal that has nothing to do with a client's use of your API, then there's no change to the semver.
Your package/container/program may change version in deployment, but that has nothing to do with the API.
If I decide to move from redis to elasticache or mysql to postgres but my API hasn't changed, that's not a change in the semver.
- dragonwriter 6y ago> Not if they don't actually change the API. If they don't effect behavior of the API, they'd be build-level, which is optional in SemVer. > If you fix an internal server bug that relates to a visible change in the API, then yes, it's a patch in the semver. Visible changes to the API are SemVer minor if they are backward compatible, SemVer major if they are not. The lower level fields of SemVer are for things that don't change the expected behavior of the public API, including (at the build level) those that don't effect visible behavior of the API. SemVer is not API versioning, it's product versioning for a product that implements an API. (I agree that something like SemVer used to version independent APIs implemented by a product is in some respect a better idea than SemVer itself, except that package management systems don't support API identification and versioning in a way which would let it be useful in most cases; SemVer is product versioning for the world where your product version needs to both tell about product increments that don't effect the public API and those that do.)