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. :)

minimum-stability is still 'dev' in the project template composer.json - has this been discussed more?

It's only dev in a non-tag situation. It gets changed to a higher level (currently alpha) by the internal ddev tag script that I use to help cut releases: https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/.ddev/commands/...

We have two dependencies that are still in alpha: Webform and Project Browser.

• Project Browser will reach beta for our release. Therefore, we'll add it to project_template/composer.json as drupal/project_browser:^2@alpha as a special exception. I'm okay with this because Project Browser is a critical piece of Drupal CMS's extensibility, and therefore adding it as a top-level requirement seems fine to me.
• I've asked if @jrockowitz can tag a beta release of Webform 6.3 in time for our release. He said it is possible, but rightfully didn't make any promises. If it doesn't land, then I'm okay with adding it as a top-level constraint (drupal/webform:^6.3@alpha) before our general release occurs.

We'll make these changes as needed, and change the ddev tag script to use "minimum-stability": "beta", in this issue.

beta is better, but I think it would be better to have minimum-stability 'stable' and individually set any projects to lower stability if necessary - this can then be removed as soon as they have stable releases.

Without this, given issues like 🐛 Display SA coverage icon based on a release/branch of the module going to be installed Active there's no way for site builders to know if projects they install have security support or not.

I pinged @phenaproxima, but it is worth noting here that Webform 6.3.x now has a beta release → . I have to thank
@acbramley and @liam morland

Thanks @jrockowitz! So there you go -- Project Browser is our only alpha dependency. We need to keep beta minimum stability for a few reasons, IMHO:

• Most people in the real world will be completely satisfied with anything that solves their problem, and I think most people will consider beta good enough.
• We have quite a few beta dependencies and I don't want to lift all of them into the project template's composer.json.
• I believe (not sure) that the security team offers coverage for beta modules?

I believe (not sure) that the security team offers coverage for beta modules?

Only stable releases, see https://www.drupal.org/drupal-security-team/security-advisory-process-an... →

Security advisories are only made for issues affecting stable releases (Y.x-Z.0 or higher / X.Y.0 or higher) in the supported major version branches. That means no security advisories for development releases (-dev), alphas, betas, or release candidates.

Most people in the real world will be completely satisfied with anything that solves their problem and I think most people will consider beta good enough.

Unless their problem includes wanting security coverage.

We have quite a few beta dependencies and I don't want to lift all of them into the project template's composer.json.

I checked all included modules now and it seems like that non-stable modules are only these:

• ai_image_alt_text - 1.0.0-beta1 - but @pameeela mentioned that they will tag stable releases
• dashboard - 2.0.0-beta2
• default_content - 2.0.0-alpha3
• experience_builder
• klaro - 3.0.0-rc16
• project_browser - 2.0.0-alpha6 - will remain alpha
• webform - 6.3.0-beta1 - I suppose they will not tag a stable release
• drupal_cms_olivero

So if at least klaro, the AI module (and maybe dashboard) tags stable versions, it does not seems that much left. Maybe we can still reconsider moving the minimum-stability to stable?

The Klaro folks are planning a stable releases "in the next 7 days", that's what they stated today in their issue queue.

Pam is the final authority here, so take my word with a grain of salt, but I think we're going to go with "minimum-stability": "beta" because that's what best fits the real-world use cases we're going after.

IMHO, beta is a reasonable balance between stability and "I need to solve my problems now". I like to be pragmatic, and my pragmatic opinion (and my experience, from my agency days) is that most site builders will happily use alpha0 releases forged in the deepest levels of hell...if it solves their immediate problem. They care more that it solves the problem (or at least appears to) than how.

Consider, also, someone trying to use Project Browser to install a target module that has dependencies that are in beta or RC stability. Putting up an unexpected brick wall because of something the site builder cannot control, and may not even care about, is the fastest possible path to disillusionment, frustration, and abandonment of Drupal CMS. Give the people what they want -- solve their problems now.

I do realize that there is a significant number of sites that care deeply about security coverage, and that beta stability will not suffice for them. That, to me, is okay -- Drupal CMS might not be the right fit for them. Most of our dependencies do have stable releases, but a couple don't (seriously, it's like 2 or 3 at this point), and I think that our target audience of ambitious marketers will be just fine with that. Many won't even know what stability levels even mean.

I just don't see how introducing a -- let's face it -- very technical and arbitrary-seeming stability barrier is going to help ambitious marketers solve their problems quickly. We don't want to give people anything insecure or unstable, but we don't want to make problem-solving unattainable or difficult.

That's why I think beta stability is the proper balance. Beta means (or should mean) "don't break me, bro". That's the priority.

I understand some of your points. I will only add what I have written earlier - if the site owner adds intentionally a non-stable module by composer, or lowers the minimum-stability, it is their decision. This decision is made by Drupal CMS and will allow all sites by default to have non-stable modules, even in the future (we cannot predict how will maintainers issue further releases). And as you wrote:

Many won't even know what stability levels mean.

- yes, many of them won't even know there can be some issues with these modules offered in a Drupal CMS stable, until a security issue or other incident happens (hopefully will not happen).

BTW, this issue probably does not need any MR if it is agreed by @pameeela that beta stability is good enough for our purposes; I already changed the minimum-stability to beta in tagged releases (see https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/.ddev/commands/..., which is the script I use to tag).

my experience, from my agency days) is that most site builders will happily use alpha0 releases forged in the deepest levels of hell

I still work for agencies and often install alpha/beta/rc modules when the need arises, but also I am often able to recognise the names of the people who built them (or notice that I don't), review their code bases and issue queues to get an idea of what sort of state they're in, debug issues if they come up, create, review, and apply patches/MRs etc. The majority of the people who work for Drupal agencies are also able to do those things.

The target audience for Drupal CMS is specifically an audience that should not be expected to do those things hopefully at all, or at least to the minimum extent possible, or at least not until they've got more Drupal experience. Project browser as an experience actively discourages this kind of deep investigation into modules because it's more app store than issue queue landing page.

Apart from this, if project browser allows installing beta stability modules, if there are five different modules that do the same thing, it removes one of the biggest guard rails towards installing something well supported, by not steering you towards the modules with stable releases.

Adding my +1 to the perspective in #26.

Given that Drupal CMS smooths over a lot of details from site builders it seems important to make reasonable decisions for them that match their preferences/risk profile.

Apart from this, if project browser allows installing beta stability modules, if there are five different modules that do the same thing, it removes one of the biggest guard rails towards installing something well supported, by not steering you towards the modules with stable releases.

I see it a little differently. Project Browser is capable of sorting by things like popularity and relevance, which are probably far more meaningful criteria to our target audience than stability alone. Example - when I'm looking for something on Packagist, there are usually 10 different packages that do more or less the same thing...and I'm going to choose the one with the most installs, or second-most installs, possibly depending on some other variables.

In other words, I think that to our target audience, a beta module with 350,000 installs (like Webform!) is going to be more attractive than a stable one with 20 installs. That's not a hard guardrail, to be sure, but it's very influential and shouldn't be discounted. I think that a minimum stability of stable will act more like a brick wall than a helpful guideline (assuming you never install any packages with beta dependencies).

beta module with 350,000 installs (like Webform!) is going to be more attractive than a stable one with 20 installs

This is sometimes the case but there are two massive caveats to it:

1. Webform is already included in Drupal CMS, so no-one is going to have to download it. This is the case for quite a few big modules. For these, Drupal CMS has already made the decision for site builders so there is none to take.

2. Webform has had dozens of stable releases in the past, that it is beta now is a temporary situation while its Drupal 11 compatibility stabilises. This is a huge difference to the hundreds/thousands of modules that have never had a stable release in their entire existence, and it's another criteria that experienced Drupal users tend to use (even subconcsiously).

Point #2 is also why I don't think it's a big deal that webform is on a beta release in Drupal CMS, because experienced Drupal developers have assessed whether it's stable enough to include (not sure about some of the others on @poker10's list though). That's not the case as soon as you start downloading new modules.

Project Browser is capable of sorting by things like popularity

Slightly off-topic, do you know if it sorts by total usage (including Drupal 7 and Drupal 10+), or if it explicitly excludes Drupal 7 usage? There are some high usage modules for Drupal 7 that are very low usage in Drupal 10 still because they're mostly obsolete/replaced at this point.

There is also the point that setting minimum-stability: stable will influence Package Manager's behavior, but not Project Browser's. So we could still find ourselves in a situation where someone finds a beta module in Project Browser, and it looks attractive and they click Install...and then Project Browser fails with a hard error arising from Package Manager because of some obscure flag in a file they didn't even know existed.

It would be a different story if Project Browser was able to sort by stability, and maybe it should, but that's not in scope for Drupal CMS. Maybe worth opening a Project Browser issue, though!

I'm also throwing my hat in for #26 and #29. The beginners who don't know the ins and outs of composer issues will most likely want guard rails to help them towards a stable, more reliable path, while the more experienced developers who just want to save time building a new site and intend to customize the site after installation will be able to customize the composer file as needed.

@phenaproxima I think installability is probably covered at least in part by 🐛 Missing information about the version of the project going to be installed Active . That's going to be more of a problem at the moment for projects without 11.x-compatible releases than it is for beta vs. rc vs. stable (unless there's some special handling for major version compatibility already?).

I (also) think it would be better to have minimum-stability 'stable' and individually set any projects to lower stability if necessary - this can then be removed as soon as they have stable releases.

Most new site builders don't know how to evaluate a particular beta for use.

Maybe the UI of project browser can try and educate users about the risks of using betas?? But that's still an _individual_ decision. I think the CMS _default_ minimum for all projects should be stable.

I also think project maintainers should make stables more often than they do. If they need to make BC changes to fix bugs, they can make a new major version.

Discussed this with @tim.plunkett and @phenaproxima and we will change the flag to stable before tagging the 1.0 release.

Thanks to everyone who contributed to the discussion :) It's been tricky to find a balance with Drupal CMS, especially with the timing of Drupal 11 meaning that many modules we needed were not initially available let alone stable. By being flexible with this throughout development, we've managed to include a lot of awesome functionality that we otherwise would have had to leave out. And we've also succeeded in getting a bunch of modules ready for D11, and stable, which likely would have taken a lot longer otherwise.

Part of what makes this a tough call is that there are still a lot of modules that don't have stable releases for D11, and these will be unavailable via PB with the flag set to stable. But on the whole I think that's less of a risk than the risk of setting a lower bar for users without their knowledge. As is already noted, the alpha/beta modules that are included have been vetted and represent and exception that we are comfortable making.

Perhaps this policy will even encourage some module maintainers to tag stable releases.

Separately it's probably worth following this up:

So we could still find ourselves in a situation where someone finds a beta module in Project Browser, and it looks attractive and they click Install...and then Project Browser fails with a hard error arising from Package Manager because of some obscure (to them) flag in composer.json, a file they don't know or care about.

I'll try to take a look at what actually happens here, and will log an issue if there isn't already one, for trying to improve this particular experience.

Agreed - thanks for the discussion and for the well-reasoned decision-making here.

I will make this change now, and also change the inter-component dependencies' version constraints to explicitly be 1.x-dev, rather than *, which makes for strange effects if you try to spin up a test project with the zip file generated for a dev branch.

Merged into 1.x and ported to 1.0.x. Thanks! Signing off, finally.

Perhaps this policy will even encourage some module maintainers to tag stable releases.

I should have said this explicitly, but yes it's what I'm hoping.

So we could still find ourselves in a situation where someone finds a beta module in Project Browser, and it looks attractive and they click Install...and then Project Browser fails with a hard error arising from Package Manager because of some obscure (to them) flag in composer.json, a file they don't know or care about.

Will try to add this to the new (or found) issue when it exists, but just noting so I don't forget - I think it would be absolutely fine for project browser to have some kind of extra confirmation step when the stability doesn't match, and then use @beta in composer require, so it's not a hard block for people installing modules, but still doesn't do it without checking first.

Automatically closed - issue fixed for 2 weeks with no activity.