Default package installation to @stable instead of default branch

[Copilot]

wp package install currently defaults to the repository's default branch (dev-main/dev-master), causing failures when that branch is misconfigured but stable releases exist. Changes default behavior to install from @stable.

Changes

Installation flow:

• Empty version now resolves to @stable instead of dev-{default_branch}
• Applies to both direct git URLs and shortened identifiers

Fallback behavior when no releases exist:

• Queries GitHub API for actual default branch
• Falls back to dev-{actual_branch} (e.g., dev-main, dev-master)
• Emits warning: "Could not guess stable version from GitHub repository, falling back to {branch} branch"

Modified functions:

• install(): Lines 227, 309 - default to @stable
• get_github_latest_release_tag(): Lines 1367-1388 - fallback logic using get_github_default_branch()

Examples

# Before: installs dev-main
$ wp package install wp-cli/server-command

# After: installs latest stable (e.g., ^2.0)
$ wp package install wp-cli/server-command

# For repos without releases: falls back to dev-{default_branch} with warning
$ wp package install repo/without-releases
Warning: Could not guess stable version from GitHub repository, falling back to main branch

Users can still explicitly specify versions:

• :@stable - explicit stable (now redundant but supported)
• :dev-main - development branch
• :v1.0.0 - specific version

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• example.com
  • Triggering command: /usr/bin/php /usr/bin/php /home/REDACTED/work/package-command/package-command/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php package install REDACTED package path d/vendor/wp-cli/wp-cli/bin/wp install (dns block)
• github.com (HTTP Only)
  • Triggering command: /usr/bin/ssh /usr/bin/ssh -o SendEnv=GIT_PROTOCOL git@github.com git-upload-pack 'non-existent-git-user-asdfasdf/non-existent-git-repo-asdfasdf.git' list (packet block)
  • Triggering command: /usr/bin/ssh /usr/bin/ssh -o SendEnv=GIT_PROTOCOL git@github.com git-upload-pack 'wp-cli-test/private-repository.git' /home/REDACTED/work/package-command/package-command/vendor/wp-cli/wp-cli/bin/wp git ndor/bin/git --local user.name /usr/sbin/bash sh wp-c�� package install n/sh tup_errors=0' '-git (packet block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Default branch to stable instead of main during install</issue_title>
<issue_description>

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

As discussed here: wp-cli/find-command#77 (comment)

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

wp-cli/find-command#77 (comment)
</issue_description>

Comments on the Issue (you are @copilot in this section)

@swissspidy 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:

package-command/src/Package_Command.php

Lines 307 to 310 in 682d8c6

	if ( '@stable' === $version ) {
	$tag = $this->get_github_latest_release_tag( $package_name, $insecure );
	$version = $this->guess_version_constraint_from_tag( $tag );
	}

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?</comment_new>

• Fixes Default branch to stable instead of main during install #195

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Package_Command.php	0.00%	13 Missing ⚠️

📢 Thoughts on this report? Let us know!

[swissspidy]

/gemini review

[gemini-code-assist]

Code Review

This pull request changes the default package installation behavior to prefer @stable versions over the default development branch. The implementation correctly introduces this logic and includes a fallback mechanism for repositories without stable releases. However, a critical issue is that the feature tests in features/package-install.feature have not been updated to reflect these significant behavioral changes. I've also identified two areas with code duplication that could be refactored to improve code maintainability. My review includes specific suggestions for these improvements.

[gemini-code-assist]

There's some code duplication here. The logic to resolve the @stable version is repeated here and again on lines 312-315 for shortened identifiers.

To improve maintainability and follow the DRY (Don't Repeat Yourself) principle, you could extract this logic into a private helper method. For example, a method like resolve_stable_version_constraint(\$package_name, \$insecure) could encapsulate this logic, making the code cleaner and easier to manage.

[gemini-code-assist]

The fallback logic to get the default branch is duplicated in the case of an HTTP error and a JSON parsing error. You can refactor this to avoid repetition and make the code cleaner by combining the checks. This also provides an opportunity to make the check for a valid response object more robust.

		$package_data = null;
		if ( 20 === (int) substr( $response->status_code, 0, 2 ) ) {
			$package_data = json_decode( $response->body );
		}

		if ( ! is_object( $package_data ) || JSON_ERROR_NONE !== json_last_error() ) {
			$default_branch = $this->get_github_default_branch( $package_name, $insecure );
			WP_CLI::warning( "Could not guess stable version from GitHub repository, falling back to {$default_branch} branch" );
			return "dev-{$default_branch}";
		}