Live data from Hacker News

Is Semantic Versioning an Anti-Pattern?

surfingthe.cloud

181–190 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#181

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 date is useless

Dates are just easier to scan by humans that just monotonically increasing numbers.

Re: Is Semantic Versioning an Anti-Pattern?

#182
Maybe I'm missing something, but to me more frequent builds make proper semver more important, not less.

An easy way of knowing which versions you should be able safely update to without breaking changes seems hugely valuable.

He talks about APIs versioning, but APIs are only a small part of the problem. How about the hundreds of libraries that my site is built with for example? Semver allows me to specify rules in my package file about whether to take only the exact version that I want, the latest patch, or the latest minor version. I didn't spot anything in the article that showed a better way of doing that.

Re: Is Semantic Versioning an Anti-Pattern?

#183
post #170
post #167

Earlier quoted context omitted.

Ordering is very different to what semantic versioning is. Semantic versioning proposes that those numbers have meaning and it's important. Whereas again, what you and I are both saying is "who cares, I want the commit". Commit + Branch means I can answer the question "is my problem fixed (or are things broken) in the newest version of the code" - which is the actual question semantic versioning proposes to answer bu…

> 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 bug is fixed and I can use the fix".

The problem is compatibility is a useless theory when you actually need to deploy to production - it either works or doesn't, and if going from version 1.0.0 to version 2.0.0 requires the same amount of testing as going from 1.0.0 to 1.1.0 then I don't know what's been accomplished. Same story with changelogs.

Re: Is Semantic Versioning an Anti-Pattern?

#185
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…

Are you saying one can't write a Rust program that is just a simple, unversioned OS native executable without any Rust-this attached, or being embroiled in Rust-that?

Re: Is Semantic Versioning an Anti-Pattern?

#186
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…

The way I tend to version websites/apps is: {visible-feature-changes}.{anything-else}

Re: Is Semantic Versioning an Anti-Pattern?

#188

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…

Are you saying one can't write a Rust program that is just a simple, unversioned OS native executable without any Rust-this attached, or being embroiled in Rust-that?

You absolutely can. Cargo is not strictly speaking required to build Rust code, it just makes it so easy virtually everyone uses it.

rustc won't ask you anything about version numbers.

Re: Is Semantic Versioning an Anti-Pattern?

#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

Re: Is Semantic Versioning an Anti-Pattern?

#190
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…

Sure, I'm not saying remove version numbers as a whole, more that semver isn't needed for something like a browser. What you've described doesn't need semver specifically
Post reply on HN