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

191–200 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#191

Post by rmattes »

extrapickles wrote: post #104
rmattes wrote: post #65

Earlier quoted context omitted.

What do you mean by risk? How would you quantify it? As I understand it, all semver is trying to tell you is when backwards-compatible changes happen, and when backwards-incompatible changes happen. If the project developer wants to add some sort of indication that "this package contains changes that are alpha quality, and may not respect semver for the next few releases" then that developer can append a pre-release…

Risk is simply an integer expressing how likely the project is to work if you use the previous release. Anything else is left up to the project to determine what things get a specific amount of risk. Or another way of putting is that the only requirement is that the risk number be correlated to the probability of running into issues running that release over the previous. Risk can even go negative to signal that the…

So it sounds like you're trying to quantify the runtime stability of a library with the risk metric: e.g. if I update this package, what are the chances that the foobaz function I'm using in that package will start giving me the wrong answer, or start crashing with the inputs I'm providing. You're right that semver does not try to solve this problem: by design it is only concerned with how to quantify changes to a public API.

If there's a risk that a package's functionality could break between releases it can be signaled through other channels. For example, you can keep unstable code in an "experimental" module, or hide unstable functionality behind a compiler flag. The binary compatibility (ABI) of a compiled package can be signaled with a SOVERSION or with symbol versioning.

I guess I would hope that the packages I use that do publish a public API don't go changing the guts of the package in possibly unstable ways, at least not without lots of testing and maybe a few alpha/beta releases to let the experimental changes stabilize with early adopters. If I was using a library where core functionality was breaking every few releases for unclear reasons, I would argue that it's probably better to just find a more stable library to use than to put the effort into quantifying instability somehow.

Re: Is Semantic Versioning an Anti-Pattern?

#192

Post by rmattes »

iopq wrote: post #77
rmattes wrote: post #65

Earlier quoted context omitted.

What do you mean by risk? How would you quantify it? As I understand it, all semver is trying to tell you is when backwards-compatible changes happen, and when backwards-incompatible changes happen. If the project developer wants to add some sort of indication that "this package contains changes that are alpha quality, and may not respect semver for the next few releases" then that developer can append a pre-release…

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.

Re: Is Semantic Versioning an Anti-Pattern?

#193

Post by Sean1708 »

thaumaturgy wrote: post #63
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…

It used to work that way, though; software in the 90s and early 2000s did have sane semantic versioning, updates were backported to earlier major versions, and revision updates generally didn't break anything in production. I bet semantic versioning is mostly championed by older veterans who have worked in maintenance or systems administration roles and are trying to get the industry to return to a versioning system…

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?

Re: Is Semantic Versioning an Anti-Pattern?

#194

Post by Anderkent »

Anderkent wrote: post #7

Rich Hickey has a great talk on this: https://www.youtube.com/watch?v=oyLBGkS5ICk Previously discussed: https://news.ycombinator.com/item?id=13085952

@williamle8300 >He's making good points, but what alternative is he offering?

Your comment is dead, but to answer the question - the alternative proposed is to encode the contract of your library in itself, and never break it, only extend it.

If you need to change the API, you don't change behaviour or signatures of your functions while preserving the names; you just add a completely new mainspace, while letting people use the old functions if they still have reason to. You don't have to keep actively supporting the old namespaces (i.e. no new bugfixes), but just need to not break the stuff that already worked.

There's some scenarios where this is hard - for example it's a web api and supporting it is costing you $$. But for things like that devs are generally aware that what they're consuming might get shut down at some point; so doing a new api, in a new namespace, and shutting down the old one at some point is not completely out of the question.

Re: Is Semantic Versioning an Anti-Pattern?

#195

Post by Sean1708 »

zilean wrote: post #181
dustinmoris wrote: post #47

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…

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

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

Re: Is Semantic Versioning an Anti-Pattern?

#196

Post by qwtel »

gkya wrote: post #140
qwtel wrote: post #123

Earlier quoted context omitted.

If knowing every detail of something was required for criticising it, writing a massive, incomprehensible document would be an effective way to dismiss any criticism out of hand.

This is the best Trumpism that I ever read anywhere. Even the Donald himself wouldn't be capable of such perfection.

i take that as a compliment.

Re: Is Semantic Versioning an Anti-Pattern?

#197

Post by kjdal2001 »

ZoFreX wrote: post #173
Piskvorrr wrote: post #162

Earlier quoted context omitted.

And worse, this process concerned only the Serenissima (i.e. the area ruled by Venice), not the entire Italy.

The comparison doesn't really make any sense - in what way is the Doge election protocol comparable to semver? It also seems weird to call something bad by comparing it to an election protocol that has been shown to be incredibly robust and was used in a prosperous city state that was successful for a very long time.

Yeah, I didn't get it either. It feels to me like he had this Italian election analogy in his pocket and couldn't wait to use it. It feels very forced.

Re: Is Semantic Versioning an Anti-Pattern?

#198

Post by csours »

fenomas wrote: 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…

I use screws and bolts in my construction, and hammers are definitely an anti-pattern.

Re: Is Semantic Versioning an Anti-Pattern?

#199

Post by euyyn »

XorNot wrote: post #183
kelnos wrote: post #170

Earlier quoted context omitted.

> Whereas again, what you and I are both saying is "who cares, I want the commit". I (not the grandparent poster) usually don't just want the commit. I want to be able to look at two versions and have a good idea if they're source and/or binary compatible. If I do need to deal with the source of the app, hopefully they're doing me a solid and tagging commits with the version number. > Commit + Branch means I can answ…

>> ...which is the actual question semantic versioning proposes to answer but can't. > No it doesn't. Semver exists to help answer the API/ABI compatibility question. It has nothing to do with whether or not your bug is fixed or not. But it has everything to do with whether other things are broken (i.e. incompatible) which is what determines whether I can upgrade or need to triage. So yes, the question is "whether my…

Going from version 1.0 to version 2.0 of a dependency might require rewriting your code, which, unlike testing, we still haven't automated.

Re: Is Semantic Versioning an Anti-Pattern?

#200

Post by matt_kantor »

wkd wrote: post #189

I don't understand why some developers insists on using semver and not follow the spec, in my opinion that is the only 'problem' with semver. If you need a version and don't care about following the spec just use a timestamp or datetime, replace it where required with a sed command and move on but please don't claim to use semver if it's just an arbitrary number for you

And if you're in some context where you're forced to use SemVer (npm, cargo, etc) but you can't be arsed to think about backwards compatibility, just bump the major version with every release.
Post reply on HN