There seems to be a confusion between versioning an
API, which is the
contract between a service and its clients; and versioning an
implementation of that API.
I version the API with semver. If I add a new optional field, that's a bump in minor. If I add to a list of enumerated strings, that's a bump in minor.
But if I change my internal database schema, that's a change in my deployed service without any change in the API.
I use date-based release IDs for the service, because it marks a point in time of my development.
So release 2020-07-29 of MyService might support API versions 1.0, 1.1, 1.2 and 2.0. Clients using 1.2 are backward compatible with 1.0 and 1.1. Clients using 2.0 are not.
2020-07-29 is useful to SREs running MyService. It's irrelevant to the clients unless it changes that list of available semver'd API definitions.
I version the API with semver. If I add a new optional field, that's a bump in minor. If I add to a list of enumerated strings, that's a bump in minor.
But if I change my internal database schema, that's a change in my deployed service without any change in the API.
I use date-based release IDs for the service, because it marks a point in time of my development.
So release 2020-07-29 of MyService might support API versions 1.0, 1.1, 1.2 and 2.0. Clients using 1.2 are backward compatible with 1.0 and 1.1. Clients using 2.0 are not.
2020-07-29 is useful to SREs running MyService. It's irrelevant to the clients unless it changes that list of available semver'd API definitions.