Background
In a software ecosystem where different packages depend on different versions of other packages, sometimes dependency resolution ends in a version conflict.
Example:
- Root package A depends on B 1.* and C 1.*.
- Package B depends on E 1.*.
- Package C depends on E 2.*. -> conflict.
Maybe the developers of library C had a discussion about whether it is ok to depend on E 2.* instead of E 1.*, and how many people this would make angry.
Maybe the developers of library E also had a discussion about whether anyone would switch to their new branch E 2., which could break compatibility with older packages which still use E 1..
I have seen discussions around this kind of problem in the PHP community, for the Composer / Packagist ecosystem. But I assume similar discussions happen elsewhere.
Question
I have been wondering, why not release a new version under its own package name and namespace? This would allow different versions to coexist without conflict.
E.g. instead of E 1.* and E 2., there would be E1 1. and E2 1.*. The package name would not be "E" but "E1" / "E2". The namespace for classes would be ACME::E1::*
or ACME::E::v1::*
, instead of just ACME::E::*
.
Or in PHP / Composer / Packagist ecosystem:
Instead of just symfony/symfony, there would be symfony/symfony1, symfony/symfony2 etc. And the namespace would be Symfony2\Component\Asset
etc.
Or maybe the version number would apply on a lower level, e.g. Symfony\Component2\Asset
.
So my question is: Is there any package ecosystem where this is common practice? Is there a good reason not to do this?