[zilean]

> Even the smallest and most stable change can break backwards compatibility

This i care about.

> fix a bug or add a new feature

Not sure why i should care about these tho.

> essentially breaking existing integration

Not sure why you need 3 numbers to express that. Am i right in that your consumers dont get bugfixes by default because api patch version is changing? How is this working irl?

> suggestion of using a date is useless

Dates are just easier to scan by humans that just monotonically increasing numbers.

[Sean1708]

  >> fix a bug or add a new feature
  > Not sure why i should care about these tho.

I'm using feature X. Feature X was introduced in version X.Y. Therefore I can't use any version less than X.Y.

  >> essentially breaking existing integration

  > Not sure why you need 3 numbers to express that. Am i right in that your consumers dont get bugfixes by default because api patch version is changing? How is this working irl?

No. When you fix a bug you increment the patch version, unless the fix changes the API in which case you wouldn't want it automatically updated anyway.

[zilean]

> I'm using feature X. Feature X was introduced in version X.Y. Therefore I can't use any version less than X.Y.

But it would work the same way with monotonically increasing version. no?

> When you fix a bug you increment the patch version

I am just trying to understand how semver applies to REST in your case. Never seen anything but single number versioning for endpoints.

[Sean1708]

  > But it would work the same way with monotonically increasing version. no?

Kinda. If I can use 1.4 then I can use 1.7 but I can't necessarily use 2.1, because 1.7 only added things to 1.4 but 2.1 changed something about the public interface.

  > I am just trying to understand how semver applies to REST in your case. Never seen anything but single number versioning for endpoints.

Sorry, I didn't realise we were talking about REST.