Package Manager's minimum stability validator doesn't properly handle stability flags

phenaproxima → credited alexpott → .

Crediting @alexpott for finding this one and reporting it to me in Slack.

Or, to put it another way, if you're updating a package you already have, minimum-stability should be ignored. It should only matter if you're adding something you don't already have.

I don't think this exactly true if you minimum-stability: beta you have an existing page that is at 1.0.0-beta1 you should not be able to update to 2.0.0-alpha1 because even though it is an update it is going from below at minimum-stability to below it

I don't think this exactly true if you minimum-stability: beta you have an existing page that is at 1.0.0-beta1 you should not be able to update to 2.0.0-alpha1 because even though it is an update it is going from below at minimum-stability to below it

Huh? Composer won't let you download alpha1 if your minimum-stability is beta, because that's how minimum-stability, like, works...am I missing something?

You could probably have a situation like the following:

1. Installed at 1.x@alpha
2. Update to 1.x@beta
3. 2.x@alpha gets released.

We'd still not want to update people to 2.x@alpha which I think is what #8 is saying.

It should update to the next release even if it is below the minimum-stability, as long it is on the same major branch.
Only allow to change from a major version branch to the next if it is stable.

1. Installed at 1.x@alpha
2. Update to 1.x@beta
3. 2.x@alpha gets released. Not update.
4. Update to 2.0 release.

I believe the example needs more than just whether it has an alpha or beta tag. Versioning can affect whether it will go to another release, and according to the composer docs acts differently if it is a pre-stable release, as in version 0.x

From: https://getcomposer.org/doc/articles/versions.md

// ~ | allows last digit specified to go up
"vendor/package": "~1.3.2", // >=1.3.2 <1.4.0
"vendor/package": "~1.3", // >=1.3.0 <2.0.0

// ^ | doesn't allow breaking changes (major version fixed - following semver)
"vendor/package": "^1.3.2", // >=1.3.2 <2.0.0
"vendor/package": "^0.3.2", // >=0.3.2 <0.4.0 // except if major version is 0

I'm not saying that there can't be any bugs in composer's upgrade calculation. And in their list, 2.0.0-beta1 is less than 2.0.0, so can it decide to upgrade to the 2.0.0-beta1 from 1.x if your minimum stability is beta, and your restriction is ~1.0, because 2.0.0-beta1 is < 2.0.0?

I agree that if minimum-stability is stable, but the individual requirement is ^2.0.0@alpha that it should upgrade from 2.0.0-alpha1 to 2.0.0-beta1, and possibly even to 2.1.0-beta
And if your individual requirement is ^2.0@alpha that it should even upgrade to 2.1.0-alpha1, or higher, according to the docs.
But if the individual requirement is 2.0@alpha, does that lock it in at alpha levels because it didn't have a ^ or ~ ???
Without documenting the actual requirements, we don't know if it was other restrictions that caused it to fail to upgrade.

Steps used to setup test project in DDEV:
mkdir testpb
cd testpb
ddev config (using defaults)
ddev composer create drupal/recommended-project (installed Drupal 11.1.5)
ddev config --docroot=web --project-type=drupal11
ddev restart
ddev composer require drush/drush (installed Drush 13.4.0)
added "drupal/project_browser": "2.0.0-beta1", to conflict section in composer.json to ensure an alpha install, since beta1 is current release.
ddev composer require 'drupal/project_browser:^2.0@alpha' (installed Project Browser 2.0.0-alpha10
ddev drush si (using defaults)
ddev drush en project_browser
ddev composer require drupal/automatic_updates:^3 (installed Automatic Updates 3.1.7)
ddev drush en automatic_updates

Went to Reports-Available Updates, clicked on manual run, and it displayed the Project Browser beta1 as available on the List tab.
On the Update tab, it showed "No update available".
Removed the conflict in composer.json for Project Browser beta1.
Reran the manual check... and got the error message that composer.json does not match the .lock file and to do a composer update.
Ran a ddev composer update --lock to get past that.
Reran the manual check and still got the message that there were no available updates.
The composer.json line for Project Browser is: "drupal/project_browser": "^2.0@alpha"
And the stability flags are: "minimum-stability": "stable", "prefer-stable": true,

The composer require for Project Browser was taken off the Alpha10 release page.
Any further changes suggested?