Basically, breaking changes (new required field or change of data type for a field in the request, complete behaviour change in processing on an endpoint, removing a field or changing its data type in a response) is a major / non backwards compatible change. Clients will have to make changes to how they consume the API before they can use this new version.
Minor is a non breaking change; new non-required request field, or loosening of a field from required to not required, new features that are off by default or only available on brand new endpoints, new optional response fields. Clients don’t have to change anything - the API will keep working regardless, but can use the new features or whatever if they want.
Patch is typically only for bug fixes or other small things that won’t break any client integrations and likely wont change any functionality but will fix functionality without breaking the API.
This example sort of makes most sense with something like a REST API, but if you think about it, the same concept works for something like a library too, except instead of calling GET /thing you call MyLibrary.thing() or whatever! So if you introduce a new parameter in thing()‘s signature which is mandatory, that’s a breaking change. But if it’s optional it’s a minor change - and if the signature stays the same but internally you fix something like tighten up security or speed up performance or whatever, that’s a patch.
Apologies for the lack of formatting - typing on my phone!! Hopefully it helps someone anyway :)
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.
Basically, breaking changes (new required field or change of data type for a field in the request, complete behaviour change in processing on an endpoint, removing a field or changing its data type in a response) is a major / non backwards compatible change. Clients will have to make changes to how they consume the API before they can use this new version.
Minor is a non breaking change; new non-required request field, or loosening of a field from required to not required, new features that are off by default or only available on brand new endpoints, new optional response fields. Clients don’t have to change anything - the API will keep working regardless, but can use the new features or whatever if they want.
Patch is typically only for bug fixes or other small things that won’t break any client integrations and likely wont change any functionality but will fix functionality without breaking the API.
This example sort of makes most sense with something like a REST API, but if you think about it, the same concept works for something like a library too, except instead of calling GET /thing you call MyLibrary.thing() or whatever! So if you introduce a new parameter in thing()‘s signature which is mandatory, that’s a breaking change. But if it’s optional it’s a minor change - and if the signature stays the same but internally you fix something like tighten up security or speed up performance or whatever, that’s a patch.
Apologies for the lack of formatting - typing on my phone!! Hopefully it helps someone anyway :)