Breaking changes in dependencies and package upgrade order

I have about 40 internal packages that i maintain with a quite complex set of dependencies used by several simultaneous game projects at different stages of development and i have a problem when i make breaking changes and the user updates the wrong package. Here is a simple example that shows the problem.

I have two packages, A and B
A has a assembly definition dependency on B.
A->B

I start with version 1 so A1 and B1

I make a breaking change to B1 and get a new version B2
Then i make a fix for A1, to do it the new way in B2 and add a dependency in the manifest to the new B2 version, and get A2.

So if the user have either of these cases
A1->B1 works
A2->B2 works

If the user updates A first and get
A2->B1
The manifest dependency automatically forces an update to B2 and it works

Is there any way to solve the problem where the user updates B first and get
A1->B2

As i understand it since B does not know A exist it cant tell A to update in this case or am i missing something?

 

First thing to note is that if A1 is installed as a direct dependency (has an entry in the project manifest) while B1 is a transitive dependency (installed as a dependency of A1 but no project manifest entry), then a user installing B2 will end up turning package B from a transitive dependency to a direct dependency i.e. a project manifest entry will be added for B2.

This is because you cannot update a transitive dependency without first creating a direct project dependency - you need to tell Package Manager that you don't want the version of B that A requested, you want a specific version of B (remember the user hasn't updated A in this scenario)

So if you update B1 to B2 and still have A1 as a direct dependency, there's now A1 and B2 as direct dependencies and they are considered as equal priority in dependency resolution. In terms of SemVer, since B2 has breaking changes, this creates a conflict with A1, which only provides a warning.

This is because it's conceivable that A1 and B2 is compatible. Rather than being pessimistic and throwing a compatibility error, we will resolve the project with A1 and B2 and see what happens (logging a warning)

That is correct although the Package Manager UI should warn if other packages in your project are using a dependency before you update that dependency. There will be a warning like "other packages are using package B, updating B may break the project, are you sure you want to continue?"