Live data from Hacker News

Is Semantic Versioning an Anti-Pattern?

surfingthe.cloud

91–100 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#91
post #78
post #72

Earlier quoted context omitted.

I'm not sure what you're trying to say. I explicitly said SemVer is for libraries and specifically for dependency management. So yeah, package managers use SemVer for dependencies. In theory you could also extend this to programming languages, but most programming languages don't do SemVer. I suppose other build tools also qualify. In any case, none of the things you use SemVer for are Continuous Delivery always-on p…

Package managers use SemVer for everything, libraries and apps. Continous delivery isn't just for web apps.

"package managers" as in apt, yum, npm, pip, etc ? They do not "use semver" for anything. Your versioning scheme is completely irrelevant to package managers. (as long as the format and separators match of course)

Re: Is Semantic Versioning an Anti-Pattern?

#92
post #70

Why is it that every time there's an article criticizing semver, the author never seems to have bothered looking at the spec? > 1. Software using Semantic Versioning MUST declare a public API. That's the very first thing it says. Semver is not meant for general apps or websites or the like, it's for APIs against which dependencies can be declared . If your software doesn't need to tell package managers about its comp…

Because people who have read the spec don't have anything to complain about.

When only nonsense is written against an idea, it's great , it shows the idea is great

Re: Is Semantic Versioning an Anti-Pattern?

#93
post #54

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…

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…

Your biggest beef with semver is that that some people don't follow the semver spec

Re: Is Semantic Versioning an Anti-Pattern?

#94

Earlier quoted context omitted.

The reasons that Rich Hickey tore into SemVer seem to be issues SemVer weren't concerned about solving and his alternatives doesn't solve the main issue SemVer was created for. The problem of "can I reasonably upgrade this library without breaking my own code, and if possible to so in an automated fashion" isn't solved by chronological versioning. If I need to upgrade my application due to a security vuln, SemVer let…

> Ultimately, the talk tears into version numbers in general, but not semantic versioning He does talk explicitly about the trouble of making major changes in SemVer[0]. The gist of his argument was that minor changes in semver are relatively useless while major changes have a high probability of breaking your software. Major changes in semver are backwards incompatible and update the program's API in place. This lea…

> As you said with SemVer, if the security upgrade is a significant change, then you can expect breakage in the library.

In practice that's very uncommon. If someone is actually doing security releases, then either they release a minimal change to supported versions, or the distributions do that for them. Actual security upgrades are normally single patches which take great care not to do any API or behaviour changes.

Re: Is Semantic Versioning an Anti-Pattern?

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

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

Re: Is Semantic Versioning an Anti-Pattern?

#96

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 s…

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

Re: Is Semantic Versioning an Anti-Pattern?

#97
post #95

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.

I don't think so. Have you got an example?

Re: Is Semantic Versioning an Anti-Pattern?

#98
post #95

Earlier quoted context omitted.

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

I don't think so. Have you got an example?

Just updated with one.
Post reply on HN