[GH-ISSUE #462] Changing requirements in dependency-fragile systems. #7311

New Issue

GiteaMirror · 2026-06-20T17:17:07-05:00

GiteaMirror commented

2026-06-20 17:17:07 -05:00

Originally created by @MrMino on GitHub (Sep 23, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/462

This was posted as a response in #148 first, but it seemed to me that this doesn't fit well there, hence a repost here:

What about dependency systems, where conflicting requirements cannot be resolved by consuming the new release of the dependency? E.g. Python:

A 1.0.0 depends on B 1.0.0
B updates to 2.0.0
A has to constrain itself to B < 2.0.0, so it updates its version to 1.0.1
New release of A requires B 2.0.0 to add a feature
There is a library C in the system that still depends on B 1.0.0.
New release of A would now break the system, since there would be two libraries with conflicting dependencies: A and C. Should the new release of A update its minor or should it update its major?

Originally created by @MrMino on GitHub (Sep 23, 2018). Original GitHub issue: https://github.com/semver/semver/issues/462 This was posted as a response in #148 first, but it seemed to me that this doesn't fit well there, hence a repost here: What about dependency systems, where conflicting requirements cannot be resolved by consuming the new release of the dependency? E.g. Python: 1. **A** 1.0.0 depends on **B** 1.0.0 2. **B** updates to 2.0.0 3. **A** has to constrain itself to **B** < 2.0.0, so it updates its version to 1.0.1 4. New release of **A** requires **B** 2.0.0 to add a feature 5. There is a library **C** in the system that still depends on **B** 1.0.0. 6. New release of **A** would now break the system, since there would be two libraries with conflicting dependencies: **A** and **C**. Should the new release of **A** update its minor or should it update its major?

GiteaMirror closed this issue

2026-06-20 17:17:08 -05:00

GiteaMirror commented

2026-06-20 17:17:09 -05:00

@jwdonahue commented on GitHub (Sep 23, 2018):

Short answer: Never knowingly ship a library/component that includes a build break, without bumping your major version number. Welcome to the world of automated continuous integration and testing.

This is the classic diamond point dependency (DPD) problem. I believe the FAQ on this issue is wrong. If you are versioning an API, what's the implementation got to do with it? If you are versioning a package, you have to ask yourself, how does semantic versioning apply to this collection of API's and implementations? Aren't the package layout and dependency manifests part of the effective interface, between you the publisher, and your customers? Who's your customer? A developer or some kind of end user? SysAdmin perhaps?

There are two interesting kinds of breaking changes. Those that break the build/environment and those that break the product (functionally). If you change from averaging over the entire collection of data points (sum and divide) to one of the common running averages, you can easily break the product without breaking the build (maybe even kill somebody). So that's an obvious breaking change that I think we all agree deserves a major version bump and some prominent documentation. If you change the mix of dependencies in your package, you might break the build, and for many of us, builders/developers are our primary customers. If builders/developers are our primary customers, then how should we categorize a build break? Even ignoring build breaks, if you force the introduction of a breaking change into the system without declaring it, you are placing the end user at risk.

There are two interesting kinds of systems. Those that allow side-by-side installation and execution (I&E) of more than one version of a package, and those that don't. The later are rather fragile to DPD issues, but both can succumb to them at various points in the product & use cycle. Interesting bugs can manifest themselves on systems that allow side-by-side I&E, when two different modules calculate a result using different versions, one of them a breaking change that did not immediately break the build/environment.

Package tooling sophistication is quite variable. Some will issue warnings or errors if you attempt to unpack something into your environment that is not compatible with existing assets, some are completely oblivious. Developer/sysadmin support for analyzing changes to dependency graphs is equally variable across the range of available tooling, but generally weak. In fact, resolving the dependency graph where version ranges are allowed, is at least an NP-hard problem on many real-world systems, made even worse by the lack of any standardized set/range semantics across the various package/feed types.

Semantic versioning is all about communicating what we know about the changes we've introduced to a product. The spec references API's quite a bit but then discusses packages and implementations as though they are all somehow interchangeable. The FAQ on this point is one critical example that should be fixed. An API is an interface definition and related documentation, not an implementation. When versioning the interface, there's no discernible dependency graph from the perspective of the publisher. When versioning a package full of dependencies and package tooling cruft, it's an entirely different matter.

Package and publication feed tooling were supposed to build on SemVer to solve the greater dependency graph problems. Thus far they have not done a very good job. They can't do that job properly without refining and extending versioning semantics. The current state of affairs has us pulling minor and patch changes automatically, in order to reduce zero-day exploit life spans, and paying a high price when our automated builds break and we are forced to deploy expensive human resources to resolve those breaks.

My short-term advice is to apply the semver rules locally, based on what you know. Be very cognizant of what it is you are versioning. If it's an API, then only breaking changes to the interface matters, because there can be no implementation dependencies. If it's a package, then the package infrastructure and layout are part of your published interface. If you take a breaking change from a dependent, you are likely going to break your customer's build, and that is a very bad thing to do! Introduce all bug fixes as patch level changes, separate from any feature additions or breaking changes. Do not assume that your products published versions will always be via your current tool set! Things are going to change.

In the long-term, participate in VersionMeta and VersionSchema. As the weather gets worse and the days shorter here in the Pacific Northwest, I should be spending some time on tooling for these projects. We need to get to a state where instead of asking "how do I force my processes/environments into compliance with this standard", to "here's our published work-flows and quality assurances" and offer a standard set of tooling around that.

@jwdonahue commented on GitHub (Sep 23, 2018): Short answer: Never knowingly ship a library/component that includes a build break, without bumping your major version number. Welcome to the world of automated continuous integration and testing. This is the classic diamond point dependency (DPD) problem. I believe the [FAQ on this issue](https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api) is wrong. If you are versioning an API, what's the implementation got to do with it? If you are versioning a package, you have to ask yourself, how does semantic versioning apply to this collection of API's and implementations? Aren't the package layout and dependency manifests part of the effective interface, between you the publisher, and your customers? Who's your customer? A developer or some kind of end user? SysAdmin perhaps? There are two interesting kinds of breaking changes. Those that break the build/environment and those that break the product (functionally). If you change from averaging over the entire collection of data points (sum and divide) to one of the common running averages, you can easily break the product without breaking the build (maybe even kill somebody). So that's an obvious breaking change that I think we all agree deserves a major version bump and some prominent documentation. If you change the mix of dependencies in your package, you might break the build, and for many of us, builders/developers are our primary customers. If builders/developers are our primary customers, then how should we categorize a build break? Even ignoring build breaks, if you force the introduction of a breaking change into the system without declaring it, you are placing the end user at risk. There are two interesting kinds of systems. Those that allow side-by-side installation and execution (I&E) of more than one version of a package, and those that don't. The later are rather fragile to DPD issues, but both can succumb to them at various points in the product & use cycle. Interesting bugs can manifest themselves on systems that allow side-by-side I&E, when two different modules calculate a result using different versions, one of them a breaking change that did not immediately break the build/environment. Package tooling sophistication is quite variable. Some will issue warnings or errors if you attempt to unpack something into your environment that is not compatible with existing assets, some are completely oblivious. Developer/sysadmin support for analyzing changes to dependency graphs is equally variable across the range of available tooling, but generally weak. In fact, resolving the dependency graph where version ranges are allowed, is at least an NP-hard problem on many real-world systems, made even worse by the lack of any standardized set/range semantics across the various package/feed types. Semantic versioning is all about communicating what we know about the changes we've introduced to a product. The spec references API's quite a bit but then discusses packages and implementations as though they are all somehow interchangeable. The [FAQ on this point](https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api) is one critical example that should be fixed. An API is an interface definition and related documentation, not an implementation. When versioning the interface, there's no discernible dependency graph from the perspective of the publisher. When versioning a package full of dependencies and package tooling cruft, it's an entirely different matter. Package and publication feed tooling were supposed to build on SemVer to solve the greater dependency graph problems. Thus far they have not done a very good job. They can't do that job properly without refining and extending versioning semantics. The current state of affairs has us pulling minor and patch changes automatically, in order to reduce zero-day exploit life spans, and paying a high price when our automated builds break and we are forced to deploy expensive human resources to resolve those breaks. My short-term advice is to apply the semver rules locally, based on what you know. Be very cognizant of what it is you are versioning. If it's an API, then only breaking changes to the interface matters, because there can be no implementation dependencies. If it's a package, then the package infrastructure and layout are part of your published interface. If you take a breaking change from a dependent, you are likely going to break your customer's build, and that is a very bad thing to do! Introduce all bug fixes as patch level changes, separate from any feature additions or breaking changes. Do not assume that your products published versions will always be via your current tool set! Things are going to change. In the long-term, participate in [VersionMeta](https://versionmeta.org) and [VersionSchema](http://versionschema.org). As the weather gets worse and the days shorter here in the Pacific Northwest, I should be spending some time on tooling for these projects. We need to get to a state where instead of asking "how do I force my processes/environments into compliance with this standard", to "here's our published work-flows and quality assurances" and offer a standard set of tooling around that.

GiteaMirror commented

2026-06-20 17:17:10 -05:00

@jwdonahue commented on GitHub (Sep 23, 2018):

@MrMino, this thread is a duplicate. Unless you intend to issue a PR or have additional questions, please close this thread at your earliest possible convenience.

@jwdonahue commented on GitHub (Sep 23, 2018): @MrMino, this thread is a [duplicate](https://github.com/semver/semver/issues?utf8=%E2%9C%93&q=diamond). Unless you intend to issue a PR or have additional questions, please close this thread at your earliest possible convenience.

GiteaMirror commented

2026-06-20 17:17:10 -05:00

@MrMino commented on GitHub (Sep 24, 2018):

Duplicate or not, this actually explained it to the point where I am fairly confident in how I should do this. Thank you.

@MrMino commented on GitHub (Sep 24, 2018): Duplicate or not, this actually explained it to the point where I am fairly confident in how I should do this. Thank you.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#7311