5 ms·

The author has actually no clue what semantic versioning is. He keeps on saying that with small, frequent and well tested changes you constantly produce "stable

The author has actually no clue what semantic versioning is. He keeps on saying that with small, frequent and well tested changes you constantly produce "stable" builds and therefore don't need the complexity of semver, but he doesn't seem to understand that this has absolutely nothing to do with semver. Even the smallest and most stable change can break backwards compatibility or fix a bug or add a new feature and semver's only purpose is to meaningfully express what kind of change it is. You build a 3rd party package or a library which is used by other people? You better use semver. It makes everyone's life easier and not more difficult. You build some REST API which is consumed by other applications? You better use semver. It not only helps to visually display what kind of change it was, but it also triggers an additional thought process during development and CI. For example if the major version doesn't change, then the CI system can reliably replace the existing API during the deployment process. However when the major version changed, then you might want to think about a side-by-side deployment to support backwards compatibility, at least for a certain grace period. It makes life in many ways easier. And again, this has nothing to do with how stable a release is. Let's say I have a public facing REST API and I make a 1 line change where I decide that some field of a JSON object must be int64 because in some edge cases an int32 wasn't unique enough and would have caused a bug. Now this change is fixing the system, making it even more stable but essentially breaking existing integrations. Semver helps me to easily communicate the change to my API consumers, setting up the right expectations and helping them and myself by reducing frustration, tech support and unwanted side effects. It also helps to deploy it in a way that allows a smooth transition to the newer API. Furthermore his suggestion of using a date is useless. What does a date tell me? Nothing... if I want to know the date I right click the files of a build and look at date + time or I look at the commit time in git or the build time in the CI tool. Having it in the version is stupid.

justicezyx 10y ago
I read the article and feels it is very poorly-written: unfounded claim everywhere, no context, no reasoning, no logical deduction, no clear conclusion ...
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.

justicezyx 10y ago

I read the article and feels it is very poorly-written: unfounded claim everywhere, no context, no reasoning, no logical deduction, no clear conclusion ...

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.