Closed kirtangajjar closed 6 years ago
This happens because we tagged the new source with v2.0.0-alpha
, which is a breaking change to Composer of course. The packages require 1.x.x
.
We need to discuss how best to handle this. Options are:
v2.x.x
branch that makes it compatible with v1.x.x
for now.v1.x.x
and v2.x.x
.Option A. is probably the easier one, but B is the one that correctly uses the dependency resolutions in Composer, so I tend to prefer B.
We can add command releases that are compatible to v2.x.x
for now, and when we're introducing breaking changes that won't work with a specific command, we can adapt that command to require v1.x.x
only.
Going through the code, I noticed that this has nothing to do with the branch alias or a tagged release.
In the package manager, we're manually setting the required version for the framework to WP_CI_VERSION
: https://github.com/wp-cli/package-command/blob/1a3eefa19d137b9587b75d419b3762d587ac2130/src/Package_Command.php#L302
This could should be adapted for to not take over the v2.x.x
signature, as our packages are not ready yet.
Working on a fix now: https://github.com/wp-cli/package-command/pull/70
It will take a few PR-back-and-forth until we have a new tagged version of the wp-cli/package-command
, which is the culprit.
@kirtangajjar The next nightly should fix this.
I tried scaffolding a command. It fails with following message: