3 ms·

> 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 a

by zilean 10y ago

> 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 10y ago
>> 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 10y ago
  > 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 10y ago
    > 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.

by zilean 10y ago

Sean1708 10y ago

>> 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 10y ago
> 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 10y ago
  > 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.