Default branch to stable instead of main during install
Bug Report
- [X] Yes, I reviewed the contribution guidelines.
- [X] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.
Describe the current, buggy behavior
As discussed here: https://github.com/wp-cli/find-command/pull/77#issuecomment-2512650398
The default behavior of wp package install is to install from the main branch. The default behavior should be to install from stable instead. As the repo is right now, an installation will fail without specifying stable. Please refer to the linked discussion for output.
Describe what you would expect as the correct outcome
No errors and a correctly installed package should occur without specifying a specific branch
Provide a possible solution
Default to stable instead of main
Provide additional context/Screenshots
https://github.com/wp-cli/find-command/pull/77#issuecomment-2512650398
I second this. It would be a much better user experience if the command was updated after a new wp-cli version was released. Otherwise the installer will wonder why their server is not allowing them to update to the latest (non-existing) version of wp-cli.
Agreed. From my perspective, it would make for an improved user experience is this functionality was handled in the way other here are suggestion. It would help prevent the kind of confusion that resulted in my creating this issue report some days ago.
Related to this:
It's possible that a new version of a package is tagged that already requires a newer WP-CLI version (either stable or nightly). In that case, even using @stable doesn't work, because right now wp package install will just pick the latest stable version and manually add it to composer.json. See:
https://github.com/wp-cli/package-command/blob/682d8c6bb30c782c3b09c015478c7cbe1cc727a9/src/Package_Command.php#L307-L310
To work around this, you'll need to either update WP-CLI (possible to the nightly build) or manually find the last possible package version that works.
Instead of manually modifying composer.json with the package version, maybe Composer itself could do this version resolution for us?