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

121–130 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#121

Post by flomo »

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 half-agree with you, because at some point, software versioning and the notion of stable apis went all post-modern (especially with open source).

But we used to pay software vendors a lot of money to care about boring things like backwards-compatibility, legacy support, and etc. Semantic versioning as a standard is a way of applying social pressure to authors to do the 'dirty work', regardless of whether they are being paid to do so. And if they don't feel like it, the result is usually "too bad for you". There's no real good answer for this that I can think of. Nobody wants to pay for leftpad.js Enterprise Edititon.

Re: Is Semantic Versioning an Anti-Pattern?

#122

Post by stormbrew »

star-trek-fleet wrote: post #114
stormbrew wrote: post #103

Earlier quoted context omitted.

I mean, yes, sure. But the spec is not the world, and there is a general trend towards literally forcing things to adopt semver even when it makes little sense. If you write a project in rust, for example, you must give it a semver number in your cargo.toml. You can give it one that makes no sense and maybe never change it or change it arbitrarily, but the implication of that field is always that it's semver. It's ri…

Given that the article did a poor job of actually stating the problem of semver, could you list the issues you encountered when dealing with rust's use of semver? I worked at Amazon for 1 year. They use semver for everything. I think that's one of a few technical superiority I missed since left. I am curious about its problems. The article did not say much. As for the suggestion given in the article, I cannot help to…

The article is poor, I'll agree with that. But the project I work on that makes me agree with it (that does not currently use rust, but it is something we're looking at) is a low level system component that is continuously deployed across entire clusters. We only ever have two versions active in a cluster at a time (either upgrading or downgrading when something goes wrong). People do not really 'consume' us except in so far as the system as a whole does expected things. We do have some "API"s to our system, and we do version those, but those protocols change extremely infrequently and are either only for consumption by the same or adjacent versions.

Our release version numbers are literally jenkins build numbers. Anything else is not worth the administrative overhead for our needs (even were that 'small', it's also weirdly political in a bikeshed sort of way).

And I don't think this is really all that uncommon even for higher level things. I don't think semver makes any sense for a rails app, for example, but in rubyland you only version things you publish. Rust makes you version things you will never publish.

Don't get me wrong. For the things we consume from outside our team or abroad, semver is an absolute boon. Sometimes, though, when you point out that people are treating something as a silver bullet, you're saying it's outright bad. I'm not saying that. It's not a problem with semver that semver is not universally applicable.

Re: Is Semantic Versioning an Anti-Pattern?

#123

Post by qwtel »

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…

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.

Re: Is Semantic Versioning an Anti-Pattern?

#124

Post by amenod »

stormbrew wrote: post #117
fenomas wrote: post #115

Earlier quoted context omitted.

Er, I don't know anything about rust but cargo is a package manager, right? And the version field you're referring to is what will get checked if someone declares a dependency against your package, right? And you're saying semver makes little sense for that?

Yes, cargo is the package manager, but it is also the build tool. Whether it's a library or a terminal project (one that has nothing depending on it) you use cargo to build it and it has a Cargo.toml. Even if nothing will ever use your package you will always have to have a version field defined in it.

Which makes sense. First of all, cargo can't know that nothing will use your package. And second of all, it is possible that this will change once someone sees how great package you've built. OTOH it costs you nothing to put a number there and never change it if there is no need.

Re: Is Semantic Versioning an Anti-Pattern?

#125

Post by dpark »

flukus wrote: post #89
dpark wrote: post #86

Earlier quoted context omitted.

Which is why I think development should be done without locked packages, locking after testing successfully before the production release. Not taking security patches is bad. Taking down production is also bad.

> Taking down production is also bad I won't say it's ever good, but for most software some downtime isn't the end of the world, certainly better than having security exploits available.

I understand that view but I think that the reality is that for many customers, downtime is worse than a potential security breach. Customers would rather downtime than a definite breach, but the chance of a breach is not always as bad as definite downtime.

I'm not saying that view is necessarily good, but I think it's common. I also think it's quite common that people assume this is the client view and act accordingly.

I definitely think skipping testing with the goal of getting security patches out sooner is a terrible plan except maybe in the case of an active exploit. You can get both frequent patches and high availability.

Re: Is Semantic Versioning an Anti-Pattern?

#126

Post by slavik81 »

flukus wrote: post #120
viraptor wrote: post #108

Earlier quoted context omitted.

I don't do C++ normally, but the situation seems similar. There's http://wiki.c2.com/?PimplIdiom for opaque objects, so you don't have to make their members part of the public API. But for things you do want to make public it's the same solution - make it a your public API by documenting it. If you know it breaks compatibility, it requires major version bump. And no, after compilation, I don't believe the symbol orde…

The pimpl method looks like it ads a level of indirection to every private member access. Is that an issue in practice?

Qt uses it extensively. For big, complex objects like QTextEdit it's probably the least of your concerns, but they do avoid it for simple value types like QPoint.

Re: Is Semantic Versioning an Anti-Pattern?

#127

Post by throwaw180ay »

The problem with semver is the actual lack of tooling built around semver. Humans aren't robots, a bug fix might actually be a breaking change, without the author noticing it. What to do in that case. Yet semver is better than nothing, all other versioning schemes are not that useful.

Re: Is Semantic Versioning an Anti-Pattern?

#128

Post by slavik81 »

fjdlwlv wrote: post #102
flukus wrote: 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.

C/C++ is hopeless for binary compatibility, under any version scheme

Qt is C++ and only breaks binary compatability on major version changes (~6 years apart).

It's hard, but certainly not hopeless.

Re: Is Semantic Versioning an Anti-Pattern?

#129

Post by MAGZine »

throwaw180ay wrote: post #127

The problem with semver is the actual lack of tooling built around semver. Humans aren't robots, a bug fix might actually be a breaking change, without the author noticing it. What to do in that case. Yet semver is better than nothing, all other versioning schemes are not that useful.

I'd say that if you can't anticipate something being a breaking change or not, then you have an architecture problem. Likely violating principle of single responsibility.

Your software should define what the inputs are and what the outputs are. It should be clear when you're breaking an interface.

Re: Is Semantic Versioning an Anti-Pattern?

#130

Post by flukus »

slavik81 wrote: post #126
flukus wrote: post #120

Earlier quoted context omitted.

The pimpl method looks like it ads a level of indirection to every private member access. Is that an issue in practice?

Qt uses it extensively. For big, complex objects like QTextEdit it's probably the least of your concerns, but they do avoid it for simple value types like QPoint.

A good chunk of these questions I'm asking are because I half remember Qt's binary compatibility guidelines from when I did an internship at Trolltech many years ago :) A similar list is here: https://community.kde.org/Policies/Binary_Compatibility_Issu... . It looks like the virtual function restrictions are what I was talking about, that's where pure additions can break compatibility.
Post reply on HN