Problem/Motivation
In composer/composer#8882, @Seldaek says:
Now obviously I can't really prove this right now, but technically this is not a bug, prefer-stable is just that, a preference. It still came up with a valid solution and that's what matters most.
Despite the disclaimer here, it is clear that the sentiment of the Composer project that prefer-stable is only a preference, and cannot be relied upon to produce a stable release. Even if one of the release candidates is stable, Composer's solution might include a non-stable version of that release; if all of the other constraints have been correctly satisfied, then the result is considered to be correct.
This means that it is unreliable to rely on "prefer-stable" as a substitute for "minimum stability: stable".
Proposed resolution
Drupal should change the drupal/recommended-project and drupal/legacy-project to use "minimum stability: stable" instead of "minimum stability: dev", so that all new sites created from the templates will use the safer setting.
The "stable" setting should, of course, only be used with stable releases of the template projects. When using drupal/core-recommended, it is necessary to use a minimum stability setting that matches the stability of the released version, i.e. beta for beta releases, alpha for alpha releases, and so on.
A new Composer script, set-drupal-version is provided for use by Release Managers to prepare Drupal for a release. This script also updates the minimum stability settings of the template projects as needed.
Usage:
$ composer set-drupal-version 9.0.0
Note that nothing can be done for existing composer-managed sites, other than provide documentation and encourage site owners to manually adjust their top-level composer.json files, as there is no update process that pulls new changes from the template projects. Template projects, as their name implies, are just templates used to create new projects; site owners assume responsibility for their top-level composer.json files.
Existing sites that are not yet Composer-managed, on the other hand, do get a new copy of their top-level composer.json file when they run drush pm-update, or update via autoupdates, so the sooner we adjust this preference, the more sites we will protect once they finally do move over to being Composer-managed.
Site owners can still use unstable modules and other unstable dependencies in their projects with the "minimum stability: stable" setting. The only requirement to do this is that all unstable requirements must be explicitly declared in the project's top-level composer.json file using version constraints that allow unstable versions.
Remaining tasks
Review and merge
Follow-on tasks
- Update drupal.org documentation with instructions on how to require modules that do not yet have a stable release.
User interface changes
None
API changes
None
Data model changes
None
Release notes snippet
As of Drupal 9.1.0-alpha1, Drupal Composer project templates declare minimum stability matching the stability of the Drupal version. In other words, the alpha releases will have a minimum stability of alpha, the beta releases will have a minimum stability of beta, and so on up to stable releases, which will require stable dependencies by default. This change was made to avoid edge cases in Composer's dependency resolution algorithm that occasionally produced unexpected results, such as upgrading to newer unstable releases rather than remaining on a current stable release.