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

131–140 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#131

Post by regularfry »

flukus wrote: post #66
eridius wrote: post #58

The author seems to be completely missing the boat here. SemVer isn't meant for Continuous Delivery production systems. Why would you even attempt to use it for that? SemVer is for libraries, and specifically for making dependency management easy. If you're not writing a library that gets distributed to other people, then use whatever versioning system you want.

> Why would you even attempt to use it for that? Can you name a package management tool that doesn't rely on SemVer?

Just because a package manager can use dotted numbers for versions doesn't mean it's relying on SemVer. Rubygems and apt, among many others, allow a wider format than X.Y.Z, and predate the SemVer spec.

Re: Is Semantic Versioning an Anti-Pattern?

#132

Post by regularfry »

sigmonsays wrote: post #29

I feel like this is a bunch of hand waving and does not really address anything but saying because we have CD we do not need to care about versions. This shows a lack of experience in a solid development process in large scale code bases.

CD itself posits that a lot of what was previously assumed to be a necessary part of large scale software delivery is just cargo culting that gets in the way.

Re: Is Semantic Versioning an Anti-Pattern?

#133

Post by verinus »

aboodman wrote: post #112

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

Software development is about communication. Quality is about discipline. So yes humans are imperfect, but SemVer works better than anything else i have encountered so far...

Re: Is Semantic Versioning an Anti-Pattern?

#134

Post by verinus »

gravypod wrote: post #61

I'm a big fan of really simple versioning schemes. . . Any version ending in a "0" is stable. IE: - 1.0.0 - 0.1.0 ..... - 999.999.0 Whenever you are doing a "release" you have tested every feature fully to make sure the software is up to spec. Whenever you are doing a "rewrite" you can assume that the software's APIs have changed and you will need to readjust compatability (ideally APIs never break but this is one ex…

I don't see an advantage over SemVer- SemVer is an accepted standard while this is not and you still have the human error component arguably beeing the weak spot for SemVer. And to be honest: this is by no means simpler than SemVer.

Re: Is Semantic Versioning an Anti-Pattern?

#135

Post by verinus »

jonathankoren wrote: post #38

Given that continuous deployment doesn't have anything like traditional releases, so why bother with semantic versioning at all. You're typically just dealing dates or monotonically increasing build numbers. There's no reason for anything else. Public APIs (including libraries), have traditional releases, and so the distinction between backwards compatible and incompatible versions really do matter. That said, a thre…

SemVer has nothing to do with CD. It's for package management. With a package or lib I don't need (multiple) daily increments as I would not update a lib I use that frequently.

Re: Is Semantic Versioning an Anti-Pattern?

#137

Post by ComodoHacker »

Author is obsessed with CD and this is the source of his misconceptions about SemVer. He probably has never dealt with really complex multi-component systems, library development or desktop off-the-shelf software.

CD is good for code you control. But for your dependencies and platforms it's the opposite. Just imagine CD of kernel patches right onto your production servers. Or CD of Java updates (or Python or whatever your app is powered with). And guess how long your system will stay "always-on".

Re: Is Semantic Versioning an Anti-Pattern?

#138

Post by wahern »

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

Linux's support for ELF symbol versioning makes maintaining binary compatibility of C libraries easier than perhaps any other platform or language. It's patterned after Solaris' ELF symbol versioning, but more powerful.

glibc uses it extensively, but alas few other people know about it. Theoretically languages, like Rust, which compile to ELF executables could leverage the capability. But none do.

There are a series of posts from a libvirt developer which explain some of the mechanics:

  https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/
I personally don't bother with semantic versioning at all. Where ABI compatibility matters, I'll commit to maintaining backward ABI compatibility in perpetuity using symbol versioning.[1] And maintaining backwards API compatibility is something I try to commit to as a matter of course; if I can't then I make sure builds will break loudly.

I don't begrudge people using semantic versioning, I don't just don't think it's the best approach for most cases. It's just one of several crappy choices. But at least with C on Linux, ELF symbol versioning is a slam dunk when you're serious about the matter.

[1] I usually avoid depending on proprietary platform features. But this is the one area I'm comfortable and eager to lean on Linux.

Re: Is Semantic Versioning an Anti-Pattern?

#139

Post by fenomas »

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.

Are you suggesting that the field should be optional, or that having the field conform to semver should be optional? If the former, then fair enough but that's orthogonal to the thread. If the latter, that would destroy the package manager's ability to resolve dependencies, right? (Unless new extra metadata was added, or somesuch.)

Either way, requiring semver formatting here sounds like its entirely justified.

Re: Is Semantic Versioning an Anti-Pattern?

#140

Post by gkya »

qwtel wrote: post #123
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.

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