Composer's "prefer-stable" setting cannot be relied on to produce a stable release

I think it would be good to have ‘stable’ as a default even if it causes some people to bump into issues installing dev/alpha release modules. Maybe it would help push module authors to release stable versions of modules (even with known issues) rather than publish an alpha for 6 years :-)

So after yet more fun in #3134648: [backport, needs scheduling] Don't pin the composer/installers version in drupal/core-recommended I think this is a critical issue. I think the default expectation for core's composer project templates should be to work with stable code. Yes our eco-system is littered with beta and rc modules but this is not good practice and we're not encouraging proper releases with this default.

Even more we're getting into situations when due this we're allowing composer update to update stable releases to unstable dev releases and that's bad.

One idea here would be to read the root composer.json and put a warning on system/reports if the minimum stability is not stable. Otherwise it's going to be hard to convert the world. Another idea is to put a check into a post-update-cmd or drupal-scaffold - I dunno.

I've been playing around with the Drupal 9 branch and the minimum stability flag on Drupal 9 and doing that gives me some thoughts.

I think the root composer.json should have the minimum-stability and prefer-stable flags removed. We should only include dev dependencies here and if we choose to depend on a dev version of something it should be explicit. This composer.json is for core development only.

I think the core/composer.json should have the minimum-stability and prefer-stable flags removed. This is not a root composer.json and these flags have no meaning.

The two project templates in composer/Template/LegacyProject and composer/Template/RecommendedProject are more interesting. If you do composer create-project drupal/recommended-project:9.0.x-dev my-project you get a project built on 9.0.x as expected. But it you do composer update you see these "interesting" set of updates

  - Updating drupal/core-composer-scaffold (9.0.x-dev 03a666b) to drupal/core-composer-scaffold (9.0.0-beta2)
  - Updating drupal/core-project-message (9.0.x-dev 571ad1a) to drupal/core-project-message (9.0.0-beta2)
  - Updating drupal/core (9.0.x-dev 3b298d8) to drupal/core (9.1.x-dev 17c7d96)
  - Updating drupal/core-recommended (9.0.x-dev e7f8caf) to drupal/core-recommended (9.1.x-dev 47e3ca1)
  - Updating drupal/coder (8.3.8) to drupal/coder (8.3.9)
  - Updating composer/composer (1.10.5) to composer/composer (1.10.6)
  - Updating drupal/core-dev (9.0.x-dev 34ab35e) to drupal/core-dev (9.0.0-beta2)

So drupal/core-dev, drupal/core-composer-scaffold, drupal/core-project-message effectively get a downgrade! drupal/core and drupal/core-recommended are upgraded! Fun!

If at this point you remove the minimum-stability and prefer-stable flags you get

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for drupal/core-composer-scaffold ^9 -> satisfiable by drupal/core-composer-scaffold[9.0.x-dev].
    - Removal request for drupal/core-composer-scaffold == 9.0.9999999.9999999-dev
  Problem 2
    - Installation request for drupal/core-project-message ^9 -> satisfiable by drupal/core-project-message[9.0.x-dev].
    - Removal request for drupal/core-project-message == 9.0.9999999.9999999-dev
  Problem 3
    - Installation request for drupal/core-recommended ^9 -> satisfiable by drupal/core-recommended[9.0.x-dev].
    - Removal request for drupal/core-recommended == 9.0.9999999.9999999-dev
  Problem 4
    - Installation request for drupal/core-dev ^9 -> satisfiable by drupal/core-dev[9.0.x-dev].
    - Removal request for drupal/core-dev == 9.0.9999999.9999999-dev

So... if you then restart the whole process and do composer create-project drupal/recommended-project:9.0.0-beta2 my-project you get the beta2 as expected.
Running composer update in the beta2 project does (amongest many other updates:

  - Updating drupal/core (9.0.0-beta2) to drupal/core (9.1.x-dev 17c7d96)
  - Updating drupal/core-recommended (9.0.0-beta2) to drupal/core-recommended (9.1.x-dev 47e3ca1)

if you change the minimum-stabiilty flag to "beta" then it results in the expected no updates.

I think I think (definitely not 100% sure) that we should only really support the templates from release candidate on. So potentially I think the flags in these composer.json files should be:

    "minimum-stability": "rc",
    "prefer-stable": true,

But I think making that change will break tests.

Note other projects which build out a recommended project - like symfony - eg https://symfony.com/doc/current/setup.html - the composer.json created does not have minimum-stability set... so maybe

    "minimum-stability": "rc",
    "prefer-stable": true,

is wrong. And we should remove them too - and only support creating stable projects. Which does make sense when written like that.

Here's a patch the removes all the prefer-stable and minimum-stability to fallback to the composer default of stable.

> I propose that we define the template projects being starting state for a stable project, regardless of the source (tag / branch) of the template project.

I agree with this. I think most people who are starting from a template are looking to build based on stable software and don't intend to run -dev releases or even betas/release candidates. Anyone who does want to try out less stable versions is welcome to do so, they just have to manually opt in to this by editing their composer.json after creating the project.

+1 also to the /composer.json and core/composer.json changes.

I did see that in composer/Template/README.txt we state:

Use Composer to create a new project using the desired starter template:

composer -n create-project -s dev drupal/recommended-project my-project

Should we be removing -s dev from here?

So it's no surprise that Drupal\BuildTests\Composer\Template\ComposerProjectTemplatesTest is failing at that calls out to packagist. See #3123933: Determine whether ComposerProjectTemplatesTest is testing the internet, and if it is, avoid that for more.

@longwave good point. Fixing the ComposerIntegrationTest too. I'm not sure how to fix ComposerProjectTemplatesTest yet.

I just wanted to note that I thought I had worked around this by running composer update "drupal/*", but apparently some other changes from 8.9.x leaked into the update still; with a fresh checkout of the codebase I was getting the error:

RuntimeException: Zend Diactoros must be installed to use the DiactorosFactory.

This looks like it's coming from the change in issue #3104015: Replace ZendFramework/* dependencies with their Laminas equivalents. So I'm going to just switch to 'stable' instead of 'prefer-stable' because I can't afford to blow up my site like this :-/

(Downstream issue in my code repo here). I'll try updating to Drupal 8.8.5 again soon, and we'll see how that goes.

It's worth seeing if we can change this during beta. In addition to the changes to our metapackages themselves, we'll also need to communicate about the risks of minimum-stability: dev to site owners who used the templates from 8.8, including instructions for them on how to use that with any pre-release dependencies or modules they have with (e.g.):
composer require drupal/module_name@alpha

We might want to spawn a series of followup/related issues for all that, not sure.

I just tried updating my Drupal 8.8.4 codebase to 8.8.5 again today, after setting minimum-stability to 'stable', and again when I try to composer install on the live site, I get the error:

In DiactorosFactory.php line 37:
                                                                 
  Zend Diactoros must be installed to use the DiactorosFactory. 

And that error comes up whether I try loading any page, or running any Drush command (including just bare drush).

It seems like somehow the changes from #3104015: Replace ZendFramework/* dependencies with their Laminas equivalents have leaked their way into my 8.8.5 code by running a composer update :-/

Apparently the issue was I had a vendor directory that still had laminas/laminas-diactoros in it. I wiped out my vendor directory and then ran composer update again, and all is working now. Sorry for the noise, but blogged about this particular composer gotcha for the benefit of anyone else who may run into a similar problem! Watch out if composer update keeps replacing a dependency.

So I've had a look at making this change for Thunder - which includes 13 less than stable projects. As stability flags can only be set on the root composer json it means that we need to add all the unstable projects to the project template like so https://github.com/thunder/thunder-project/pull/14/files. This would be the same for any project that wishes to change their minimum-stability setting. Obviously Thunder doesn't really want to add all of the distribution dependencies to the project template. That kinda defeats the purpose of separating the project and distribution composer.json files. Our plan would be to change the minimum stability to alpha and then to work with the contribute projects to get stable releases.

Core's templates now don't rely on any unstable packages (yay!) so as @xjm has pointed out the big problem to be solved here is one of communication. If we make the change suddenly:

composer create-project drupal/recommend-project
composer require drupal/access_unpublished

will not work.

composer create-project drupal/recommend-project
composer require drupal/access_unpublished:1.0.x@alpha

will though.

The recent changes to core/tests/Drupal/BuildTests/Composer/Template/ComposerProjectTemplatesTest.php are not making this any easier. Locally the test fails for me with

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package drupal/core-composer-scaffold could not be found in any version, there may be a typo in the package name.
  Problem 2
    - The requested package drupal/core-project-message could not be found in any version, there may be a typo in the package name.
  Problem 3
    - The requested package drupal/core-recommended could not be found in any version, there may be a typo in the package name.
  Problem 4
    - The requested package drupal/core-vendor-hardening could not be found in any version, there may be a typo in the package name.
  Problem 5
    - The requested package drupal/core-dev could not be found in any version, there may be a typo in the package name.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
 - It's a private package and you forgot to add a custom repository to find it

In order to get composer create-project to obey the minimum-stability flag you pass in you can't provide a version so I've removed that but still no dos.

In order to get composer create-project to obey the minimum-stability flag you pass in you can't provide a version so I've removed that but still no dos.

What do you mean here? There is no such thing as passing in the minimum-stability flag. The option stability on the create-project refers to the project package. Only needed when letting composer decide the package version. So, not applicable when specifying an exact version. The minimum-stability for the project you are creating doesn't even need to be in the composer.json as it is the default to go for Stable.

The create-project has two steps, first step downloads the project package, the second step executes an install. The first step uses the --stability to download the correct version of the project package assuming you let composer determine which one to choose. The second step does an install based on the configuration provided in the downloaded composer.json.

#22 also contains a bunch of changes to the installer that are seemingly not for this issue.

@mmjvb I was trying to point out that the command in the test in HEAD is odd because it provides both a version and a stability argument. You're totally correct though that we can't change the minimum stability in HEAD. We need to do this in the code that creates the subtree split - so I think that's https://bitbucket.org/drupalorg-infrastructure/subtree-splitter/src/master/ ... or maybe we need to adjust the tools that update things when we tag a release. Yeah I think that's it - looking at https://git.drupalcode.org/project/drupal/commit/dc8689f - this commit will need to change minimum-stability accordingly.

As far as I can see there won't be a code change to core if we make this change. It's going to be all tooling and communications.

@greg.1.anderson nice work and sleuthing.

I think though that what's in the template should reflect the \Drupal::version. So if we're on 9.1.x then minimum stability should be "dev", if we're on 9.0.0-beta3 it should be "beta" and if we're on 9.0.0 it should be "stable". So whatever process makes all the changes as per https://git.drupalcode.org/project/drupal/commit/dc8689f should be responsible for this. Also it'd probably be good to bring the part of that process that updates composer.json's into core so it can be tested and supported.

@greg.1.anderson yep it does sound about right. I'm very much in favour of adding the "change composer.jsons in core for a release script" to core.

+1 to @greg.1.anderson's idea.

@greg.1.anderson but if we did this as part of the release tagging process then the subtree splitter would not have to do a thing. Right? And then the release tags have the correct composer.json files and not only the subtree splits. I think this should be do in core.

I've practiced what we're saying on a client project that uses the drupal/core-recommended package. Removing the minimum-stability flag was painless. Composer had already done the right thing and added stability flags to the dev dependencies, eg. "drupal/encrypt": "^3.0@RC",, so changing the flag broke nothing. Obviously there's a little bit of luck that none of my dependencies dependencies where not stable.

On the subject of dependencies dependencies, for example the Thunder project is declared stable whilst it relies on alpha code, it's been said that it is an opinion that Thunder is not actually stable. This opinion does not really translate to the composer world. You are only as stable as your dependencies. At this point you have two options. Either to set your minimum-stability to alpha (Thunders are all alpha or above) or manually include each dependency with the correct stability flag.

Possibly related?

Rerolling patch for the latest head! Please review!

It still needs a release note, which would help move it forward.

+++ b/core/tests/Drupal/BuildTests/Composer/Template/ComposerProjectTemplatesTest.php
@@ -267,7 +282,10 @@ protected function makeVendorPackage($repository_path) {
+      // Also skip the projects that are symlinked in vendor. These are in our
+      // metapackage. They will be represented as path repositories in the test

Nit: Metapackages should probably be plural here?

Also a CR.

Nits and questions. Looking good!

1. +++ b/composer/Composer.php
   @@ -21,10 +24,97 @@ class Composer {
   +    if (empty($args)) {
   +      throw new Exception('Must provide Semver version as an argument.');
   +    }
   +    $version = array_shift($args);
   

   Should we also just to be careful check that there is only 1 argument passed.

2. +++ b/composer/Composer.php
   @@ -21,10 +24,97 @@ class Composer {
   +  /**
   +   * As part of the Composer Project Template test, set the version of Drupal.
   

   Since this is called from \Drupal\Composer\Composer::setDrupalVersionScript() it is not just for the test. It is for the release process too, correct?

3. +++ b/composer/Composer.php
   @@ -21,10 +24,97 @@ class Composer {
   +   * @param string $version
   +   *   Semver version to set Drupal's version to.
   +   */
   ...
   +    // Update the template project stability to match the version we set.
   +    return static::setTemplateProjectStability($root, $version);
   

   Need a @return here.

4. +++ b/composer/Composer.php
   @@ -21,10 +24,97 @@ class Composer {
   +    // satisfies '*' throws an exception if $version is not valid.
   +    Semver::satisfies($version, '*');
   

   This comment doesn't seem clear that it is referring to the Semver::satisfies() method. At first I read it just as the comment line needed to be capitalized. We could fix the comment to be more clear but since \Composer\Semver\Semver::satisfies() actually relies on \Composer\Semver\VersionParser::normalize() to throw the exception for an invalid version why don't we call it directly:
   (new VersionParser())->normalize($version);
   Then we don't have to explain why we are using '*' for the constraint.

5. +++ b/composer/Composer.php
   @@ -49,4 +139,19 @@ public static function drupalVersionBranch() {
   diff --git a/composer/Template/README.txt b/composer/Template/README.txt
   
   diff --git a/composer/Template/README.txt b/composer/Template/README.txt
   index 47c95f1c5c..31c316c19b 100644
   
   index 47c95f1c5c..31c316c19b 100644
   --- a/composer/Template/README.txt
   
   --- a/composer/Template/README.txt
   +++ b/composer/Template/README.txt
   

   Should we make a follow-up to update this readme to include a note about requiring non-stable modules and themes? Or is this just standard composer workflow so no need to have our own documentation?

6. +++ b/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php
   @@ -7,6 +7,7 @@
   +use Drupal\Composer\Composer;
   

   Unneeded use statement.

7. +++ b/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php
   @@ -162,6 +163,11 @@ protected function setUp() {
   +    // Preserve the test site if environment variable is set.
   +    if (getenv('DRUPAL_BUILD_TEST_PRESERVE_TEST_SITE')) {
   +      $this->destroyBuild = FALSE;
   +    }
   

   It this just to make the test run faster? Is this an out of scope change?

   Also since this is in a test base class is there any concern with this change in non-core tests?

   Just checking

I don't understand the purpose of the introduced change on #50.
use Composer\Semver\VersionParser; is already there, so why add use Composer\Semver\VersionParser as SemverParser;? If there is a sound reason for this, it should be at the very least documented somehow — ie, in a code comment — why it is needed.

Greg said it was an accident and he'd fix it (via Slack)

All the points in my review in #48 were addressed by @greg.1.anderson in #49 thanks!

a couple more small things

1. +++ b/composer/Composer.php
   @@ -5,7 +5,10 @@
   +use Composer\Semver\Semver;
   

   Not used anymore

2. +++ b/composer/Composer.php
   @@ -21,10 +24,104 @@ class Composer {
   +    $args = $event->getArguments();
   +    if (empty($args) || (count($args) > 1)) {
   

   won't mention but since there is at least 1 changed needed.

   Is args guaranteed to an array? If so this could just be
   if (count($args) !== 1)
   but since \Composer\EventDispatcher\Event::getArguments() doesn't use a return type declaration the current code is probably safer.

   so I guess no change

3. +++ b/composer/Composer.php
   @@ -21,10 +24,104 @@ class Composer {
   +  protected static function getDrupalRoot() {
   ...
   +  public static function getDrupalVersionScript(Event $event) {
   ...
   +  public static function setDrupalVersionScript(Event $event) {
   

   Speaking of return types. Should we add return type declarations to all the new functions add in this class?

#56 seems good to me as far as not changing anything for 2,3
1 fixed.

Looks good to me

hmm so I ran the script.
`composer set-drupal-version 9.0.3-alpha1`
It works as expected but I am wondering if we should actually the change the message

Updated Drupal version to 9.0.3-alpha1 (alpha release)

if I was Drupal user and just looked at scripts in my composer.json and saw set-drupal-version this could be confusing. What does it do? Is how I update Drupal?

Should we add something in the conformation message that says this is only for the release process?
Or even a prompt that says something like “this is a script intended for drupal.org release process. are you are sure…..?”
Or even a required --set-release-version option that you would have to actually read the function docs to know about. So nobody would run the accidentally.
changes to composer/Template won’t be bad for site but changing \Drupal::VERSION🙀

@greg.1.anderson suggested maybe we don't need this under scripts at all since the test calls it directly the release process could use another method to call it.

1. #60 looks a good solution the problem in #59.

   I tried
   php -r 'include "vendor/autoload.php"; \Drupal\Composer\Composer::setDrupalVersion(".", "9.1.0-alpha1");'
   and this produced the same changes as the composer script.

2. There is still the Needs documentation updates tag

   Should make an issue in https://www.drupal.org/project/user_guide to add a explanation in 3.5. Using Composer to Download and Update Files
   ?

3. We still haveNeeds release manager review but perhaps @xjm or @catch will be the committer to look at this?
4. I think the patch looks good. RTBC 🎉

if I was Drupal user and just looked at scripts in my composer.json and saw set-drupal-version this could be confusing. What does it do? Is how I update Drupal?

Should we add something in the conformation message that says this is only for the release process?

Worth noting that scripts in /composer.json are *only for core development* and should only be seen by users getting drupal via a git clone. All other methods at this point will not have that script.

Normal drupal users should never see that...

So I think #56 is okay, and @tedbow mentioned in slack

yeah I guess I am fine 56 also in that case

(because we already warn people that the git clone is not the product: https://git.drupalcode.org/project/drupal/-/blob/9.0.x/composer.json#L61-72)

1. +++ b/composer.json
   @@ -97,6 +97,7 @@
   +        "drupal-version": "Drupal\\Composer\\Composer::getDrupalVersionScript",
   

   This is an interesting command to add given composer already has composer show. Why have we added it?

2. +++ b/composer/Composer.php
   @@ -21,10 +23,86 @@ class Composer {
   -    $generator->generate($event->getIO(), getcwd());
   +    $generator->generate($event->getIO(), static::getDrupalRoot());
   ...
   +  /**
   +   * Get the root path of this Drupal codebase.
   +   *
   +   * @return string
   +   *   The full path to the root of this Drupal codebase.
   +   */
   +  protected static function getDrupalRoot() {
   +    return realpath(dirname(__DIR__));
   +  }
   

   While this change looks sensible - is it actually required? The reason I ask is that DRUPAL_ROOT and discovering using dirname() breaks if the composer directory is a symlink. There are issues about this for core.

3. +++ b/composer/Composer.php
   @@ -21,10 +23,86 @@ class Composer {
   +  public static function setDrupalVersion($root, $version) {
   ...
   +  protected static function setTemplateProjectStability($root, $version) {
   

   I think given the fact this code is new we should be using scalar typehints and return typehints.

4. +++ b/composer/Composer.php
   @@ -21,10 +23,86 @@ class Composer {
   +    $drupal_static_source = preg_replace('#const VERSION = [^;]*#', "const VERSION = '$version'", $drupal_static_source);
   +    file_put_contents($drupal_static_path, $drupal_static_source);
   

   There doesn't appear to be a test that tests this has actually occurred explicitly.

5. +++ b/composer/Composer.php
   @@ -21,10 +23,86 @@ class Composer {
   +    // Update the template project stability to match the version we set.
   +    return static::setTemplateProjectStability($root, $version);
   

   It's pretty surprising this returns the stability. It seems a shortcut to help tests but I think the test could call VersionParser::parseStability($version); on the version they've just passed in. Also in the test that we have so far stability is always going to be stable right?

6. +++ b/composer/Composer.php
   @@ -21,10 +23,86 @@ class Composer {
   +      exec("composer --working-dir=$dir config minimum-stability $stability", $output, $status);
   

   There doesn't appear to be a test that tests this has actually occurred explicitly.

7. +++ b/core/tests/Drupal/BuildTests/Composer/Template/ComposerProjectTemplatesTest.php
   @@ -126,14 +121,24 @@ public function testTemplateCreateProject($project, $package_dir, $docroot_dir)
   +    // Set the Drupal version and minimum stability of the template projects
   +    $stability = Composer::setDrupalVersion($this->getWorkspaceDirectory(), $simulated_stable_version);
   

   I think we should test the explicit affects that we think this command should have here.

I updated the CR with some edits,

And I also noticed this:

+++ b/composer/Composer.php
@@ -21,17 +23,71 @@ class Composer {
+      exec("composer --working-dir=$dir config minimum-stability $stability", $output, $status);

Is there any chance / does it have much impact if 'composer' isn't in $PATH?

should this use /vendor/bin/composer? Or am I being paranoid?

I think we should open up a couple of follow ups for this as well:

1. Drupal.org has composer suggestions on the release node pages. These should be updated to reflect these suggested stability flags:

2. It would be nice to provide the end users with a message that informs them about the stability flag options when they run into trouble requiring a package:

Example: With minimum-stablility:"stable" When users run 'composer require drupal/webform:^6.0' (which only has an alpha release so far) They see:

Composer 1

./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package drupal/webform ^6.0 is satisfiable by drupal/webform[6.x-dev, 6.0.0-alpha1, 6.0.0-alpha2, 6.0.0-alpha3, 6.0.0-alpha4, 6.0.0-alpha5, 6.0.0-alpha6, 6.0.0-alpha7, 6.0.0-alpha8, 6.0.0-alpha9, 6.0.0-alpha10, 6.0.0-alpha11, 6.0.0-alpha12, 6.0.0-alpha13, 6.0.0-alpha14, 6.0.0-alpha15, 6.0.0-alpha16, 6.0.0-alpha17, 6.0.0-alpha18, 6.0.0-alpha19, 6.0.0-alpha20] but these conflict with your requirements or minimum-stability.


Installation failed, reverting ./composer.json to its original content.

Composer 2

./composer.json has been updated
Running composer update drupal/webform
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/webform ^6.0, found drupal/webform[dev-6.x, 6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x)] but it does not match your minimum-stability.

You are using a snapshot build of Composer 2, which may be the cause of the problem. Run `composer self-update --stable` and then try again. In case it solves the problem, please report an issue mentioning Composer 2.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

It might be nice if we could somehow add a message that says "You can override your minimum-stability for this package by using a stability flag like so: composer require drupal/webform:^6.0@alpha, via a plugin or other mechanism.

Oher than my one question above and the request for follow ups, this is RTBC to me, but I'll wait until I hear further responses.

Actually, Friday is the alpha1 deadline, so, yes, this is good to go afaict. If there *is* an issue with paths, its going to be insanely rare, like, a release manager is running their script inside of a stripped down docker container kinda thing, which, we can always work around.

I agree with #70 - the code looks good, the change record is good, and the release note looks good too. Obviously we now need to make some noise so that contrib author's know that stable releases will make things easier for their users.

This looks encouraging to me, although didn't do a line-by-line review yet, and the alpha would be the best release to give it a first run on.

Removed this from the issue summary since it was outdated:

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

This is the recommended way instead - just tried it out on a throwaway clone:

php -r 'include "vendor/autoload.php"; \Drupal\Composer\Composer::setDrupalVersion(".", "9.1.0-alpha1");' 

We need to update the following documentation to include this information after commit:

https://www.drupal.org/core/maintainers/create-core-release
https://www.drupal.org/core/maintainers/create-core-security-release

And also: https://github.com/xjm/drupal_core_release/

Tagging 'needs follow-up' for the d.o changes too.

Added a PR for the release tagging script: https://github.com/xjm/drupal_core_release/pull/13

core/tests/Drupal/BuildTests/Composer/Template/ComposerProjectTemplatesTest.php:128:11 - Unknown word (fufill)

Fixed typo on commit.

core/tests/Drupal/BuildTests/Composer/Template/ComposerProjectTemplatesTest.php:312:42 - Unknown word (symlinked)

Added to dictionary on commit.

Committed d72c583 and pushed to 9.1.x. Thanks!

Still needs the documentation updates and follow-ups created - I've run out of time for this afternoon so hoping someone else can take those!

Tagging 'needs follow-up' for the d.o changes too.

That is now done with https://git.drupalcode.org/project/drupalorg/-/commit/bb17ababeb29722e83..., for example https://www.drupal.org/project/webform/releases/6.0.0-alpha20

Did some more work on the release note. It's longish, but I think it needs to be to help people understand whether they're affected.

I think some mention of how to override the minimum stability for specific packages would be useful in the release notes.

E.g.:

Projects that depend on one or more unstable dependencies can still set their minimum stability to stable by using stability flags: e.g.: package@alpha.

Is the release note the place for that or is it sufficient to put it all in the change record?

Good point @Mixologic. I concur that the CR is sufficient. Thanks.

9.1.0-alpha1 was tagged, packaged, and split : Looks good: https://github.com/drupal/recommended-project/blob/9.1.0-alpha1/composer...

We still don't quite have the secret sauce for the pre-release milestones' templates: #3179061: Further discuss use of "prefer-stable" and "minimum-stability" in core

I don't think that's a regression necessarily as it likely happened with earlier alphas too; just a "remaining not-quite-fixed" part of the issue.