4 ms·
>> 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
by 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.