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

111–120 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#111

Post by dbaupp »

flukus wrote: post #78
eridius wrote: 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.

What does a package manager "using" SemVer for apps look like in any meaningful way? The package manager never has to do any dependency resolution against the version number of an app, so, I would assume (and know, for the package managers I'm familiar with), the version number is just an arbitrary sequence of three numbers. A version number only becomes semantically relevant the machine when other things depend on (aka, use the public API of) it.

Re: Is Semantic Versioning an Anti-Pattern?

#112

Post by aboodman »

SemVer is awful. Yes, even for libraries.

The only purpose of SemVer is to express whether a change is breaking or not. It fails at that. Nobody can predict whether a change is breaking. Because code is complicated, and code with dependencies is exponentially complicated.

At best SemVer communicates from one human to another the _expectation_ about whether a change is breaking. The expectation can, and frequently is, broken.

All changes are breaking changes. Vendor your dependencies by hash. Humans cannot be trusted.

Re: Is Semantic Versioning an Anti-Pattern?

#113

Post by grey-area »

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…

Isn't cargo a tool for sharing code?

If you share code you should use semver, because someone will (hopefully) import it and use it, and it communicates your expectations of stability.

Re: Is Semantic Versioning an Anti-Pattern?

#114

Post by star-trek-fleet »

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…

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 think that one can always release a number based on a semver to external customers. That does not prevent semver being used internally at all.

> a general trend towards literally forcing things to adopt semver

This statement assumes that semver is bad if forced universally, which may or may not be the case.

Your comment include no fact that this is bad. When you mentioning rust, you also did not say anything why semver is bad.

I mean, if someone put an arbitrary number there, and users are screwed because of author fails to maintain the correct contract, at least people can go to there and point out that the contract is broken. Removing semver does not do anything good. It just give the author an possible excuse, i.e., if users are screwed, the author can claim that he/she never meant to make its software backward compatible. For that, semver also provides the same mechanism, i.e., bump a major version number. At lease users know that they can expect a breakage.

Re: Is Semantic Versioning an Anti-Pattern?

#115

Post by fenomas »

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…

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?

Re: Is Semantic Versioning an Anti-Pattern?

#116

Post by justicezyx »

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…

IIRC, Amazon deprecates old versions after some time period. That solves the "no one wants to update" problem. It also shows clearly that when a major version will not be maintained regularly.

Re: Is Semantic Versioning an Anti-Pattern?

#117

Post by stormbrew »

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

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.

Re: Is Semantic Versioning an Anti-Pattern?

#118

Post by regularfry »

kaspm wrote: post #60
Groxx wrote: post #49

Earlier quoted context omitted.

Ehhh... at best it argues that it's over-complicated for something that only ever has a single version running everywhere. Like a web service that you control, for which there will never be a way to request "use that old version of the code instead".[1] Which is true. But then why even bother with YYMM.xxxx? Just use a single incrementing integer. Or none - nothing can ever go backwards, so callers are required to ig…

Yeah okay. I think there is a very large group of developers who work in just such an environment: developing web applications that have a "production" version whether they are public internet or internal to companies where the previous version would literally _never_ be consumed. The reason to track a increment in that kind of environment is as a code to align feature requests to a particular release (usually by dat…

In the past I've used YYYYMMDDXX as a version number. In my experience there's no real problem with confusion about what the version number means as long as it's automatically generated so there's a clear definition. For me it was "feature merges to master, and master has passed tests". Nothing about actual releases at all, because the version of the code says nothing about what you do with it.

Re: Is Semantic Versioning an Anti-Pattern?

#119

Post by [deleted] »

kaspm wrote: post #60
Groxx wrote: post #49

Earlier quoted context omitted.

Ehhh... at best it argues that it's over-complicated for something that only ever has a single version running everywhere. Like a web service that you control, for which there will never be a way to request "use that old version of the code instead".[1] Which is true. But then why even bother with YYMM.xxxx? Just use a single incrementing integer. Or none - nothing can ever go backwards, so callers are required to ig…

Yeah okay. I think there is a very large group of developers who work in just such an environment: developing web applications that have a "production" version whether they are public internet or internal to companies where the previous version would literally _never_ be consumed. The reason to track a increment in that kind of environment is as a code to align feature requests to a particular release (usually by dat…

[deleted]

Re: Is Semantic Versioning an Anti-Pattern?

#120

Post by flukus »

viraptor wrote: post #108
flukus wrote: post #105

Earlier quoted context omitted.

> That's how successful C libraries do it. What about c++? Object allocation is always handled by new on the consumer side isn't it? Also in C, does the order of function declarations matter?

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?
Post reply on HN