Alpha stability flag in composer.json allows project_browser to download any alpha stabiility module

This is problematic because the alpha dependencies are indirect dependencies, and stability flags are respected at the root level only.

It's set to dev, which I guess is even worse?

It's only dev in our development branches. For tagged releases, it is alpha. See https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/.ddev/commands/...

Ah you fancy! I take it back

There was a discussion about possible outcomes when using minimum-stability together with prefer-stable: #3179061: Further discuss use of "prefer-stable" and "minimum-stability" in core → . Not sure everything applies also to Drupal CMS structure, but I think that under some circumstances, using minimum-stability: alpha with prefer-stable: true could have caused a downgrade.

This is problematic because the alpha dependencies are indirect dependencies, and stability flags are respected at the root level only.

Can the root level specify the alpha indirect dependencies with @alpha directly then? This could be removed as soon as those projects as stable releases or are otherwise not included as alpha releases. Haven't thought through the full consequences of this so it could easily cause other problems.

My only problem with that is the possibility of cruft. For example, if we remove Project Browser from our dependencies -- let's say because it gets into core -- people who started with Drupal CMS will be stuck with it in their composer.json.

Granted, once recipe unpacking is a thing, that will be true anyway, so perhaps it's not that big of a deal.

I'd like to discuss with @tim.plunkett before rolling an MR.

Responding to some comments on 🐛 Security Advisory coverage status is hardcoded on Recipes Active .

@pameela

If you were starting a new project today that had to use webform, would you really use D10 so that you had security coverage?

I would use the alpha, but there are mitigating factors:

1. I've got 20 years of Drupal experience and know how to apply patches and debug things if they go wrong.
2. If I start a project now and use an alpha release, there is a non-zero chance the project will have a release candidate or stable release by the time that project launches.
3. I would rather spend time helping get modules stable on a new major release, than deal with a major core update 6 months later. Not necessarily because it's less work, but because it feels like a choice between spending time usefully on things that benefit all Drupal websites rather than busywork within an individual project.

For the same reasons, I have existing Drupal 10 sites that I probably won't start updating to 11.x until mid-2025 in the hope that the total amount of hours/budget spent on updates will be lower in mid-2025 than it would be now (or in 2026 when Drupal 10 is nearly out of support and contrib has moved on). e.g. if they have 50 modules installed and 30 of them are alpha now but will be stable in May 2025, that's a lot less to worry about.

However Drupal CMS is primarily aimed at non-technical Drupal users, and my understanding of it is it's specifically supposed to remove a lot of those considerations when building a site.

@poker10

But Drupal CMS/Forms recipe/PB will make the decision (without acknowledgment) instead of users, which is the difference.

Yes this is the difference for me too.

The webform recipe isn't enabled by default, so it would be entirely possible to remove it from Drupal CMS today.

If project browser can install recipes, then individual sites can make the decision to install the recipe, or webform directly, but if Drupal CMS's minimum-stability is stable, then project browser should prevent that from happening.

But then site owners have workarounds they can make (like lowering minimum stability themselves), or as soon as there's a stable tagged release, it would work.

grep -rl "webform"
drupal_cms_forms/tests/e2e/contact_form.cy.js
drupal_cms_forms/recipe.yml
drupal_cms_forms/content/shortcut/create-form.yml
drupal_cms_forms/config/captcha.captcha_point.webform_submission_contact_form_add_form.yml
drupal_cms_forms/composer.json

This isn't really ready for any changes yet. :)