🔖 Versioning and Evolution of the API

The API uses the SemVer pattern. In this sense,
compatible changes should not generate a new major version.

The API version consists of 4 elements: major, minor, patch e release candidate.
The version v[x] in the URL path is the element major of the API version.
The evolution of the version is as follows:

• Major: incompatible changes with breach of contract (v1.0.0 → v2.0.0)
• Minor: compatible changes without breach of contract (v1.1.0 → v1.2.0)
• Patch: bugfixes, clarification to specifications, without functional changes (v1.1.1 → v1.1.2)
• Release candidate: pre-release versions of any future patches, minor ou major (v1.0.0-rc.1 → v1.0.0-rc.22)

Changes without breach of contract and clarifications to specifications can occur at any time.
Customers must be prepared to deal with these changes without breaking.

The following changes are expected and considered backward compatible:

• Addition of new features in the API.
• Addition of new optional parameters.
• Adding new fields to API responses.
• Changing the order of fields.
• Adding new elements to enumerations