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

101–110 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#101

Post by viraptor »

flukus wrote: post #95
viraptor wrote: post #90

Earlier quoted context omitted.

Have you got an example where pure addition breaks the existing compatibility? > the lie that people will do security and other updates on older versions. Semver does not say anything will be supported. You still have to know what's going on with your dependencies as far as big releases and patches go. It simply says that is old versions are still supported, they're updates will preserve compatibility.

> 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.

Normally in a library you'd provide functions that allocate and free structures defined by that library. That's how successful C libraries do it.

I think semver covers this pretty well actually. The public API is not just the function signatures, but basically anything that makes your API - whether it's code or documentation. So either:

- your structs in the library are opaque and the library handles all the memory management itself - addition of fields is backwards compatible, or

- your structs are open and your functions expect the structs from outside - addition of fields is not backwards compatible

The second one is still falls under "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API."

To make a comparison in a dynamic language: you've got public function `f(d)` where `d` is some dictionary with elements `a` and `b`. Now in the next version you start to require `c` - same signature in the code, but it's not backwards compatible. It's still a public API, even if defined by the documentation.

Re: Is Semantic Versioning an Anti-Pattern?

#102

Post by fjdlwlv »

flukus wrote: post #95
viraptor wrote: post #90

Earlier quoted context omitted.

Have you got an example where pure addition breaks the existing compatibility? > the lie that people will do security and other updates on older versions. Semver does not say anything will be supported. You still have to know what's going on with your dependencies as far as big releases and patches go. It simply says that is old versions are still supported, they're updates will preserve compatibility.

> 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

Re: Is Semantic Versioning an Anti-Pattern?

#103

Post by stormbrew »

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 right there in the docs: http://doc.crates.io/manifest.html

This is a real procedural problem that is being created by a "silver bullet" approach to versioning that the semver people can deny they're trying to create, but is happening anyways.

Re: Is Semantic Versioning an Anti-Pattern?

#104

Post by extrapickles »

rmattes wrote: post #65
extrapickles wrote: post #50

I never really liked semver as its a mixture of release number and an abstraction/categorization of risk that nobody can agree on, making it hard to tell how stable an update will be. It was fine back when you only had a release or two a year, but now the abstraction is no longer good enough. I prefer the first number to be a simple release number, then the second to be the amount of risk from the previous release. T…

What do you mean by risk? How would you quantify it? As I understand it, all semver is trying to tell you is when backwards-compatible changes happen, and when backwards-incompatible changes happen. If the project developer wants to add some sort of indication that "this package contains changes that are alpha quality, and may not respect semver for the next few releases" then that developer can append a pre-release…

Risk is simply an integer expressing how likely the project is to work if you use the previous release. Anything else is left up to the project to determine what things get a specific amount of risk. Or another way of putting is that the only requirement is that the risk number be correlated to the probability of running into issues running that release over the previous. Risk can even go negative to signal that the previous release had a showstopping bug that was fixed and that the new release should be used in all cases over the previous.

Also, some of the risk calculation can be pushed down onto tooling and the community. As an example, if more than the normal amounts of issues are reported against a release, the risk for the release can be automatically increased without anyone needing to be diligent in updating it and things can get automatically rolled back if the change was found to be too risky.

Semver requires a project to be more diligent than many projects are willing/able to be, and requires all changes fit nicely into the semver categories. Too many changes don't fit neatly into semver, especially when libraries are used cross platform and in different programming languages. Say a project switches from GCC to Clang, semver has no official way to express that. Release.Risk can handle it by assigning a amount of risk to the update and pretty much any other unforeseen corner case too as it doesn't try and categorize the risk. Also different projects have different risk profiles which semver completely ignores the concept of (glibc is more risk adverse than the JS library of the day). Semver also doesn't indicate any difference between a new feature that is self contained or one that touches a core piece of code, the former is much less risky than the later.

Re: Is Semantic Versioning an Anti-Pattern?

#105

Post by flukus »

viraptor wrote: post #101
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.

Normally in a library you'd provide functions that allocate and free structures defined by that library. That's how successful C libraries do it. I think semver covers this pretty well actually. The public API is not just the function signatures, but basically anything that makes your API - whether it's code or documentation. So either: - your structs in the library are opaque and the library handles all the memory m…

> 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?

Re: Is Semantic Versioning an Anti-Pattern?

#106

Post by fenomas »

viraptor wrote: post #90
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…

Have you got an example where pure addition breaks the existing compatibility? > the lie that people will do security and other updates on older versions. Semver does not say anything will be supported. You still have to know what's going on with your dependencies as far as big releases and patches go. It simply says that is old versions are still supported, they're updates will preserve compatibility.

> Have you got an example where pure addition breaks the existing compatibility?

Surely they're mutually exclusive terms. I think GP was talking about cases where the developer releases a change thinking it's just an addition, but it actually breaks compatibility.

Of course, that boils down to saying that software updates sometimes have bugs. What that has to do with semver, I have no idea.

Re: Is Semantic Versioning an Anti-Pattern?

#107

Post by caf »

viraptor wrote: post #101
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.

Normally in a library you'd provide functions that allocate and free structures defined by that library. That's how successful C libraries do it. I think semver covers this pretty well actually. The public API is not just the function signatures, but basically anything that makes your API - whether it's code or documentation. So either: - your structs in the library are opaque and the library handles all the memory m…

your structs are open and your functions expect the structs from outside - addition of fields is not backwards compatible

Sometimes it's possible to handle this case (if you've planned ahead) by including unused space within the original struct defintion that you can then repurpose later.

Re: Is Semantic Versioning an Anti-Pattern?

#108

Post by viraptor »

flukus wrote: post #105
viraptor wrote: post #101

Earlier quoted context omitted.

Normally in a library you'd provide functions that allocate and free structures defined by that library. That's how successful C libraries do it. I think semver covers this pretty well actually. The public API is not just the function signatures, but basically anything that makes your API - whether it's code or documentation. So either: - your structs in the library are opaque and the library handles all the memory m…

> 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 order matters.

Re: Is Semantic Versioning an Anti-Pattern?

#109

Post by fenomas »

unsoundInput wrote: post #41
nemothekid wrote: post #15

Earlier quoted context omitted.

The reasons that Rich Hickey tore into SemVer seem to be issues SemVer weren't concerned about solving and his alternatives doesn't solve the main issue SemVer was created for. The problem of "can I reasonably upgrade this library without breaking my own code, and if possible to so in an automated fashion" isn't solved by chronological versioning. If I need to upgrade my application due to a security vuln, SemVer let…

I think this talk makes his opinion on how breaking changes in libraries should be handled (in the context of the JVM ecosystem) very clear: A) avoid breaking API changes B) if you have to do large breaking API changes, that will probably affect alot of dependent projects, make it a new artifact / namespace / library that can live side-by-side with the old version B is actually pretty common in large java library pro…

Isn't semver the best way to do what he's advocating, then?

I mean, it's not like people delete 1.3.0 from their packaging system when they release 2.0.0. Incrementing the major version number is semver's way of declaring a new namespace, and once declared, it lives alongside the old ones.

What is Hickey suggesting be done differently?

Post reply on HN