A breaking change in your dependencies is a breaking change for you. If it weren't, minor version upgrades would cause you to pull in incompatible dependencies.

This is why keeping your dependency list as tiny as possible is imperative.

Wait, I'm confused. Say I'm the author of a library. Some of my dependencies had breaking changes, but they didn't affect the users of my library, as it's handled in some method.

Should that be a new major version of the library?

The sensible default answer with no context is: bump your major version as well.

The more nuanced answer is that it depends on your packaging system and your language runtime. If either cannot handle more than one minor version of a dependency at the same time, you need to bump a major version. The problem is that the code that uses your library might also indirectly be using that dependency, but pinned to a different major version. This means that the application is broken even though the breaking changes aren't used by your library.

To illustrate:

   apple-1.0 => banana-1.0   => carrot-1.0
             => broccoli-1.0 => carrot-1.0

Say, as the maintainer of banana-1.0 want bug fixes in carrot-2.0, so you pull it in and bump your minor version. And then an application updates it dependencies.

   apple-1.1 => banana-1.1   => carrot-2.0
             => broccoli-1.3 => carrot-1.1

In some, though not many, systems, you can pull in two versions as if they were different libraries. But in almost all, you get a dependency conflict and apple will be broken.

Even if you can juggle two dependencies of the same library, you need to make sure there wouldn't be any logic changes that would break the system or even corrupt data (!).

Anyway, it's simpler to be conservative and bump the major version. Yes, that can be a pain. But, again, it's good to keep your dependency list small or at least very boring to keep that pain to a minimum.