In my previous post I shared an example of how dependencies could break under vgo when semantic versioning rules are broken. That post talked about people, trust, and tooling in relation to MVS. One of the pieces of feedback I got was that the example could be more clear. So, here goes…

A Quick Recap

The underlying issue in the previous posts example had to do with Helm using gRPC. gRPC broke from semantic versioning by changing behavior in a non-backwards compatible way but only incremented the minor release version. The API didn’t change but the behavior behind it did. This caused consumers of gRPC, in Go, to experience a breaking change.

Helm And When It Is A Dependency

This diagram illustrates an application importing Helm (which imports gRPC) and importing gRPC for other purposes. I’ve skipped the other dependencies to keep the concept simple. The darker the background color the more insight into the dependency and how it is used is known by the app author. That’s why the application that imports Helm is the darkest.

Having trouble reading the dependency Helm has? It says “gRPC (> 1.0, < 1.4)”. The light color illustrates the difficulty of knowing what’s going on with it due to distance in knowledge from its usage.

Under vgo and MVS there is no way to communicate a maximum version. MVS will pickup the App needs version 1.8.0. In this case that will break Helm without there being an error, compiler or otherwise. See the previous post to understand the nature of the error.

Dependency managers in other languages and even those in Go today (e.g., dep and Glide) will tell the App author about the problem. Not so with vgo and MVS as there is no way to capture the maximum version much less use it.

Note, Helm now uses a version of gRPC newer than 1.4. This is about illustrating a problem we previously encountered to share how examples like this can play out in the future.