问题
Let's say I have a core CMS which has been upgraded from v4.8.7 to v5.0.0
I also have an events module package with it's own version number 1.2.4 which imports this core CMS package in it's composer.json file:
"company-name/cms": "^4.3",
I upgrade the composer.json file on this package to become:
"company-name/cms": "^5.0",
But how do I mark this change with semantic versioning?
Should it be marked as a breaking change and thus mean the submodule version number would become 2.0.0 or should it be marked as a minor/patch?
I'm thinking it would need to be marked as a major change otherwise running composer update on projects that use the package may cause an error if the parent package is out of date but just wanted to gather opinions.
回答1:
From a purely SemVer perspective, this is really dependent on tool chain capabilities and conventions, as well as the kind(s) of breaking changes in your transitive dependencies.
Some tool chains will block a non-breaking update that contains breaking transitive dependencies, issue a warning, and not break your customers ingestion and build processes, if; they can complete the build's dependency graph, by skipping the non-breaking update. Others will throw an error, and prevent the build from completing.
Build breaks aren't the only transitive dependency issue however. You will cause pain if you introduce a transitive behavior, that modifies the effective functionality of your component, to the extent that your customers code will break when it runs. This of course would not be a concern with a tool chain that prevents such an update from taking place.
Put yourself in your customer's shoes and think about the tool chains they might be using to ingest your package. How much pain are you willing to inflict on them?
来源：https://stackoverflow.com/questions/59247866/should-a-package-major-version-change-mean-a-sub-package-major-version-change