> Why? That's the practical effect of cascading breaking changes through the dependency tree anyway. It isn’t. That’s my point. > I can't substitute the old t

> Why? That's the practical effect of cascading breaking changes through the dependency tree anyway. It isn’t. That’s my point. > I can't substitute the old thing with the new thing, so why not just give the new thing a new name? You can’t substitute it with zero effort. The work involved may be as minimal as a single change in a single place. Of course it might be much more than that. If that’s the case, I think this “new package” = “new name”, while still subjective, becomes a valid concept to consider. But that depends not just on the scope of changes: the nature of what changed, why, and how it manifests downstream all matter. A great example of what you’re proposing, that seems to have gone well (despite much consternation about it at the time), was the transition from the original Angular.js to Angular 2. A wholly different project, positioned as such. It becomes more questionable to justify the concept for a release with substantive breaking changes, but which nonetheless undeniably remains a spiritual successor. And it becomes absolutely silly when such substantive changes, while breaking, are absolutely in line with the intent of the original package. An example of this I encountered yesterday, granted still in proposal, is a change to Zod’s union APIs which brings them much more in line with their original goals and with their original underlying rationale. This would be a breaking change, but if anything it would make the package more true to itself rather than another package. Downstream dependent packages will necessarily make changes to adopt the proposal. But I’d be utterly shocked if anyone would argue, in good faith, that it makes Zod itself meaningfully different to the degree it should be renamed to make the change. As for cascading changes, it’s entirely possible to encapsulate such that it doesn’t need to happen, just as you say. But it’s also just as reasonable that some changes, breaking though they might be, are objectively good for both the originating package and downstream users. It may be the case that cascading the change is exactly what everyone in that chain wants to happen, even as they consume the same set of packages. Versioning can be very good at conveying changes like this! Arbitrarily declaring that any change of this kind must warrant a rename would almost certainly be more disruptive than that. Even if it’s philosophically sound (and here I will just say that it’s famously not), it’s pragmatically… goofy.