Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Semantic Versioning an Anti-Pattern?

surfingthe.cloud

Post reply on HN
Print view View original

211–219 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#211

Post by dragonwriter »

No, but the use case he criticizes it for (a first-party service) is outside the scope of SemVer, so applying SemVer there would be an antipattern. That's generally true of apply a good pattern outside of its explicit domain.

You use SemVer when you are distributing a software package supporting a public API to third parties. If you are just running a service thst you develop.In house supporting a public API, you don't need SemVer. Arguably, SemVer is less useful if the software supports multiple public APIs for which independent, versions specs are available, though it is still meaningful and may be worthwhile in that case; though simple sequential versioning with a statement on API version compliance of each product version is probably more valuable.

Ultimately, it's a matter of choosing the right tool for the job, and SemVer is well-suited to the job it is intended for.

Re: Is Semantic Versioning an Anti-Pattern?

#212

Post by taeric »

viraptor wrote: post #90
taeric wrote: post #54

Earlier quoted context omitted.

My biggest beef with semver is that it is pushed by people encouraging this concept that additions are always safe. Or the lie that people will do security and other updates on older versions. By and large, especially in an org, if you make a change that requires another place to change, you should go ahead and make that change. Period. Thinking people can stay on the old version till they want to update is BS. They…

Have you got an example where pure addition breaks the existing compatibility? > the lie that people will do security and other updates on older versions. Semver does not say anything will be supported. You still have to know what's going on with your dependencies as far as big releases and patches go. It simply says that is old versions are still supported, they're updates will preserve compatibility.

Sorry for the very late response. I should have written it as "additions are safe." I am more reflecting on additions being more liability (commonly called "tech debt") that you have.

I think others covered the edge cases where additions literally break. The sibling that said I was likely referring to just plain bugs hits it pretty well, I think. I was not going for esoteric scenarios.

And yes, semver doesn't say anything about if a version is supported. However, it is a strong indication that it is. In a social expectations sort of way. If you don't plan on supporting old versions of what you are doing... use a new name for the new stuff. Nobody expects google guava to support apache commons, even though they are doing a lot of the same things. We do expect, however, that apache commons will make sure any bugs in old versions are dealt with.

Re: Is Semantic Versioning an Anti-Pattern?

#213

Post by stymaar »

mikekchar wrote: post #17
ryan_lane wrote: post #10

This post completely ignores one of the most important features of semver, which is dependency management. Being able to do this is really great: some-library>=1.0.0, It means I can include a library and get non-breaking changes and all security updates until the next major release without worrying that a change is going to break me randomly. It doesn't mean I don't need to do testing, but it makes it a lot more like…

Possibly if you have very few dependencies, and those also have very few dependencies it will work out OK. But in a lot of circumstances, this is a recipe for shooting your foot off. For example, if you are building a server application in Node and the total number of included packages can reach into the thousands. And then if you deploy to your server and for some reason it has to update NPM, suddenly you have a pot…

> And then if you deploy to your server and for some reason it has to update NPM, suddenly you have a potential of any and all of those thousands of packages to break, or interact poorly, or whatever. Since you have specified that anything between 1.0.0 and 2.0.0 is perfectly fine, you have absolutely no idea what secret sauce is necessary to get a working application again.

That's not how you're supposed to use npm. You should never perform an npm update directly in production exactly because of what you describe.

The proper way to manage dependencies update in npm is to perform the dependencies' updates in your build process when building your pre-production/staging build and then use the shrinkwrap[1] command of npm to generate a file with all dependencies pinned for production. This way, for a given production deployment, you know exactly what version of which dependencies was being used and you can rollback easily if an update break something.

[1] https://docs.npmjs.com/cli/shrinkwrap

Re: Is Semantic Versioning an Anti-Pattern?

#214

Post by netheril96 »

flukus wrote: post #95
viraptor wrote: post #90

Earlier quoted context omitted.

Have you got an example where pure addition breaks the existing compatibility? > the lie that people will do security and other updates on older versions. Semver does not say anything will be supported. You still have to know what's going on with your dependencies as far as big releases and patches go. It simply says that is old versions are still supported, they're updates will preserve compatibility.

> Have you got an example where pure addition breaks the existing compatibility? With c/c++ additions can break binary compatibility can't they? Adding a field to a struct for instance will mean existing code that does a malloc for that struct won't allocate coorectly. I think there are a million other cases to consider too.

> Adding a field to a struct for instance will mean existing code that does a malloc for that struct won't allocate coorectly.

Really? Do you ever call `malloc(4)` instead of `malloc(sizeof(int))` or `malloc(sizeof(*ptr))`?

Re: Is Semantic Versioning an Anti-Pattern?

#215

Post by Sean1708 »

zilean wrote: post #207
Sean1708 wrote: post #195

Earlier quoted context omitted.

>> 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. Wh…

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

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

Re: Is Semantic Versioning an Anti-Pattern?

#216

Post by iopq »

rmattes wrote: post #192
iopq wrote: post #77

Earlier quoted context omitted.

Well, backwards-compatibility is sometimes a probability. For example, a change in the public signature of a function to accept a wider class of arguments might be considered backwards-compatible since the previous calls to the function will still work. But if your language has type inference, now the previous calls have to actually specify the type of their arguments since the type inference algorithm can no longer…

That's an interesting point. If you're using a language that adds more rules to the API compatibility than the language that a module is released in, it's probably not possible to rely on semver in the general case. Unless the author is aware of those issues and versioning accordingly, any minor release could be breaking.

Even in the same language, how do you prove that your changes didn't break things like type inference? Any change to the signature of a function (even accepting MORE types than before) can potentially break someone's code.

Re: Is Semantic Versioning an Anti-Pattern?

#217

Post by Sean1708 »

taeric wrote: post #201
Sean1708 wrote: post #193

Earlier quoted context omitted.

I'm not sure I understand your argument. If someone's not going to backport a v2.1 fix to v1.6, why would they backport a v20170106-1009 fix to v201610-1005?

I'm not sure what you are saying. My argument is that it is a myth that most things will get only security updates. That is, the version scheme States the point is to somehow be in a position to get only security updates. However, unless there is an org specifically for maintaining a library, your only hope of getting updates is to take all updates. So, to stay on the latest.

I think I must have got myself confused at some point, disregard my previous comment.

Re: Is Semantic Versioning an Anti-Pattern?

#218

Post by rmattes »

iopq wrote: post #216
rmattes wrote: post #192

Earlier quoted context omitted.

That's an interesting point. If you're using a language that adds more rules to the API compatibility than the language that a module is released in, it's probably not possible to rely on semver in the general case. Unless the author is aware of those issues and versioning accordingly, any minor release could be breaking.

Even in the same language, how do you prove that your changes didn't break things like type inference? Any change to the signature of a function (even accepting MORE types than before) can potentially break someone's code.

If you can't definitively prove that a class of changes won't break things, then you probably have to treat that class of changes as breaking and version accordingly, no?

Re: Is Semantic Versioning an Anti-Pattern?

#219

Post by dwheeler »

xj9 wrote: post #4

i don't like the scheme described in the article, but i do think that X.Y.Z is overkill. X.Y provides plenty of information and doesn't make me second guess if i should upgrade or not. Z often creates a false sense of confidence that shit wont break. changes in X always mean breakage, changes in Y mean potential, but unintended, breakage.

The problem with two-part numbers is that they look like floating point. Both humans and tools can easily sort them as 4.1, 4.11, 4.2.

Three-part is unambiguous.

Post reply on HN