Determine some heuristics for feature inclusion to avoid conflicts with core and difficult upgrade paths for sites

We have already had conversations about some of the specific cases referenced here, but agree it would nice to have some underlying principles written down.

More questions have come up since I opened this originally.

If someone installs Drupal CMS 1.0.0, should they expect that all of the modules that come with it are covered by the Drupal security team?
If so, should they also expect that if they install Drupal CMS 1.0.0-rc1?

If they install 1.0.0-beta1 (or rc1 for that matter) should they expect to be able to continue building their site on it if they don't run into problems, and then use automatic updates to update the various modules installed?

Following.

As far as I know, the Drupal CMS project does not change expectations about what it means when a maintainr opts into security coverage or does/doesn't make a stable releases.

I don't think it changes expectations about the modules, but I think that people installing Drupal CMS will have expectations about security support, or if they don't, would expect to be able to find out what the parameters are.

Drupal CMS doesn't pin dependencies to a specific release, only major or minor (and IMO can't pin any further than that, because sites are responsible for updating modules after that).

So in that sense unless there is a security issue in a recipe (wrong permission granted to wrong role or similar), or a zero-day in a module that needs mitigation (removing permissions or a feature), then a security release for a module is only an issue for a site - new Drupal CMS users will get it automatically.

So then the main risk for a module that is on an non-release branch or not opted into security support is that a security issue found would be opened in the public queue.

For modules with multiple branches where some are stable, it's more likely to be reported and fixed in private, but with the development branch either fixed on the same day as a 'bonus' or lagging behind by a few hours or days. This overall doesn't feel too bad, we would want to encourage module maintainers to add a new alpha/beta/rc promptly at least.

For modules not opted in at all, or which have never had a stable release, then we're looking at more likelihood of issues being disclosed pubicly and possibly not fixed in a timely manner too. The more sites install Drupal CMS, the higher the usage of those modules will be, so this will gradually become more of a problem.

From a non-security perspective there's also the issue that an alpha release of a module makes zero promises about upgrade path, but we want sites that install Drupal CMS to be able to update when newer releases of modules come out, so included modules really need to be at beta or rc stability or higher from that perspective.

We are likely to have some alphas in the initial release, but pretty much only because of D11 support. Project browser is also alpha currently, not sure what point it will be at in Jan though.

I don't think we can say definitively that we won't ship with any alpha modules. We'd love not to, but it was a battle to even get D11 fixes committed and tagged at all.

Certainly, all of the modules we'd conceivably be shipping as alpha already have a stable release so I think the risk is heavily mitigated as @catch pointed out. The alternative was to stay on D10 and have our pick of stable branches!

For modules with multiple branches where some are stable, it's more likely to be reported and fixed in private,

Unless the issue affects only the non-stable branch - in such case, it can be disclosed publicly (and even if not, the fix will be without SA, so sites will not be notified properly). Not each module has an active development, releasing major/minor versions regularly. Some modules are stuck on a non-stable branch for a long time and differences between branches can be pretty big. I am not talking only about modules included in the Drupal CMS dev branch right now, because this is not only a question about the 1.0 release.

Certainly, all of the modules we'd conceivably be shipping as alpha already have a stable release so I think the risk is heavily mitigated as @catch pointed out.

There are some without any stable releases (therefore not covered at all):

• dashboard 2.0.0-alpha1 (not covered, no stable releases)
• friendly_captcha_challenge 0.9.18 (not covered)
• project_browser 2.0.0-alpha5 (unstable, no stable releases)
• gin 8.x-3.0-rc14 (rc, but still unstable with no stable releases)
• gin_toolbar 8.x-1.0-rc6 (rc, but still unstable with no stable releases)

I have not checked all modules

Personally I do not think that Drupal CMS should beg maintainers to create a stable releases - it should be the other way - there should be an effort from the maintainers, to have a module in a best possible condition, to be included in the stable Drupal CMS (I know this a very idealistic perspective).

Just one additional example - the Dashboard module is not covered by SA policy, has no stable releases. It has a text "Use at your own risk!" on the module's page. The dashboard recipe is included in the starter recipe, so we are going to install this module to all sites.

@pameeela do you think this is correct from the security and stability perspective? Should we require at least the modules which are in the starter recipe + in all other recipes, which are installed automatically, to have stable releases? Otherwise I cannot fully imagine what will the Drupal CMS 1.0 (stable) mean.

Dashboard, Gin (+ Gin Toolbar) and Project Browser are all essentially Drupal CMS initiatives and their maintainers are working closely with us. Ideally, they all will have a stable release by January but I don't feel that it is essential that they do.

Right now, it is true that Dashboard is not really ready for use. We hope to have it ready for our release, not sure what more I can say. Whether it will be removed if it isn't stable is probably a call for Dries to make as the project lead.

friendly_captcha_challenge is basically a library, so that we can ship with the dependencies for friendlycaptcha, because there is no good way to manage front end dependencies in Drupal. But also it is maintained by one of our track leads, and he can tag a stable release when needed.

Personally I do not think that Drupal CMS should beg maintainers to create a stable releases - it should be the other way - there should be an effort from the maintainers, to have a module in a best possible condition, to be included in the stable Drupal CMS (I know this a very idealistic perspective).

I think this is a great aspiration, and hopefull will be the case in the future. But the timings of all of this were not ideal -- especially because D10 has LTS and many module maintainers were not in a hurry to get D11 ready -- and it's what ended up happening. As I said, the alternative was to ship on D10 and that was determined to be a worse option. It was also the case that the Drupal CMS team and contributors were able to help many of the modules achieve D11 readiness, so most certainly we have accelerated the pace of D11 adoption which is a great outcome.

As to documenting policies, if we set strict rules at the beginning before we understand the reality that we are working in, I think it will only create more problems. So we are probably more in a situation where we will document what we have done and create policies for the future, rather than saying now exactly what we will do in January. I realise this is not ideal but it's what happens when you move fast :)

I think this is a great aspiration, and hopefully will be the case in the future. But the timings of all of this were not ideal -- especially because D10 has LTS and many module maintainers were not in a hurry to get D11 ready -- and it's what ended up happening.

Another alternative would have been to commit to a timeline for a beta/release candidate but not a stable release, to give these modules an extra few weeks to become stable.

The main concern for me with something like navigation is less the security support aspect (although there are scenarios where that could be very bad), but whether there will be some kind of schema change without an upgrade path while it's still beta, breaking sites that have installed it.

While Drupal CMS isn't responsible for providing an upgrade path, it is responsible for installing sites which might not have one, so then should only include ones that will. Possibly there are no schema changes for navigation planned or an upgrade path will be provided if there are, but I don't know the answer to that, and nor will anyone else without doing a fair bit of research or talking to the maintainers.

@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.

I think this was worked out between this and other discussions. I'll close so any new conversation is based on updated info.

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