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

141–150 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#141

Post by Xylakant »

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

Earlier quoted context omitted.

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

If your issue is with the format and the contract that semver enforces, then you can easily number your builds .0.0 That's valid semver, it follows the contract. Major versions may break compatibility or may not. There's no contract that enforces that non-breaking changes can only go into minor or patch releases. The only baggage you'll be carrying around will the the two trailing zeroes. You're unlikely to run out of available major version numbers any time soon.

Re: Is Semantic Versioning an Anti-Pattern?

#142

Post by Xylakant »

taeric wrote: post #54
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…

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…

> Or the lie that people will do security and other updates on older versions.

counterpoint: rails. At least two versions are supported at any time, sometimes older versions still receive fixes for critical security issues. Rails follows semver and they're doing fairly well. I rarely see breakages from upgrading anything but major releases.

Re: Is Semantic Versioning an Anti-Pattern?

#143

Post by pjmlp »

stormbrew wrote: post #103
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 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…

Microsoft learned the hard way what it means not to enforce versions, hence why .NET also forces versioning at the dynamic loader level.

Java build tools are also built on top of versioning.

Re: Is Semantic Versioning an Anti-Pattern?

#144

Post by Freak_NL »

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

Earlier quoted context omitted.

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

For this scenario you seem more opposed to the idea of version numbers in general then Semver. Does your build process tag the build numbers in your code repository? The benefit of Semver (and any sensible versioning system) is that whatever you deploy in production gets a (human readable) version assigned to it, and that version is tagged in your git/hg/svn repo.

The nice thing about version numbers such as Semver is that whenever you do need to maintain more than one branch of your library/tool/application, its just a matter of branching the code, and assigning a higher major version to the newer branch, whilst keeping the older major version for the stable older branch (which will still receive fixes).

With build numbers you lose a way to distinguish these two, with Semver you have an old branch (v1.0.0, v1.0.1, v1.1.0, …) and a newer branch (v2.0.0, v2.0.1, …) that can both receive new updates and version numbers. Because you usually can't predict which internal project will by necessity get split into two parallel development branches, you might as well just use version numbers everywhere.

I don't quite get the administration argument you mention. A lot of modern build software (Rust is mentioned, but Java does this as well with Maven) use some sort of versioning to facilitate this out of the box, so why go out of the way to not use them?

Re: Is Semantic Versioning an Anti-Pattern?

#145

Post by verinus »

As has been stated SemVer is primarily for Libs.

But I want to argue one point: that versioning APIs would be simpler than versioning a component/lib.

If a lib exposes one API seperating the version numbers would result in two.

If we look at exposed API and differentiate by purpose (a good idea imho) we would have multiple version identifiers- one for each API and one for the component.

I thought about API versioning and testing (a special kind of unit test to verify the contract an API promises) but I don't think we are prepared for such complexity.

Re: Is Semantic Versioning an Anti-Pattern?

#146

Post by nstart »

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…

First thought when reading this article. I fell into this trap too when developing my software stuff and then realised that I was just trying to force something that didn't make sense. My apps don't contain anything that has breaking changes for anyone else. And since then I've become more pragmatic about versioning. Now I don't really bother when it comes to web apps I build. The git commit id hash is good enough for me.

Re: Is Semantic Versioning an Anti-Pattern?

#147

Post by Freak_NL »

jayflux wrote: post #12

I feel like semver works great in the right context, for example if I'm building an API/Library which other deveopers are using, it helps them to know if there's been a major version bump, breaking change or just general patches. However if it's just software for the end user, such as a web browser, it doesn't make as much sense, what is defined as a breaking change for someone browsing the web? And will they care? I…

As a developer I really like to know which version of a browser a user is running to be able to reproduce a specific bug. It does matter if they are using a five year old browser or the latest evergreen update of Firefox. Having the version number available somewhere (Help » About …) facilitates communication a lot.

Also, for corporate customers it is sensible to agree on the version range supported for a web browser if you are offering a SaaS solution, especially if security matters.

Re: Is Semantic Versioning an Anti-Pattern?

#149

Post by digi_owl »

In the end adhering to semantic versioning indicates a commitment to maintaining parallel lines of development. One that breaks APIs, one that maintains them (but may introduce other changes), and one that involves only bug fixes.

These days though the mantra seems to be "push to prod", and thus you may as well increment the major number on every push...

Re: Is Semantic Versioning an Anti-Pattern?

#150

Post by mixedbit »

Recently I discovered a problem I was completely unaware of with dependencies management using semantic versioning patterns. My invalid understanding was that if I specify a dependency pattern:

foo-lib >= 1.0, I will always update to the newest 1.X.Y version of the foo-lib.

This is not the case, such pattern can silently install one of the older 1.X.Y releases due to the requirements of other libraries that my software uses and that are out of my control.

This is pretty dangerous, the pattern treats all 1.X.Y as equally good for me, but X and Y updates can contain important, often security related bug fixes.

A safer way would be to be able to say: I want to have the newest 1.X.Y, fail if it is not possible, so I can investigate.

Post reply on HN