A version number is a communication device for breaking changes. If nothing breaks, do not bump it.
Adding an endpoint, adding an optional parameter, adding a field to a response, adding a new enum value that clients can ignore — these are additive and should ship continuously. If your consumers cannot tolerate a new field appearing in a response, that is a client robustness problem worth telling them about, not a reason to fork your entire API.
Reserve the version bump for the changes that genuinely break somebody: removing or renaming a field, changing a type, making an optional parameter required, changing default behavior, changing error semantics, tightening validation.
The uncomfortable observation I keep coming back to is that a lot of versioning is a coping mechanism. A team was pushed to ship on a date, got the design wrong, and rather than fixing the design they shipped v2 and left v1 running forever. Now they maintain two of everything permanently. Versioning absorbed a business problem — unrealistic deadlines and insufficient design time — and converted it into a maintenance liability.
Also worth noting: most of the largest API providers do not do textbook semantic versioning, and their consumers are fine. Stability of behavior and clear communication of change matter far more than the elegance of your numbering scheme.
