Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
With both core and contrib modules, stability can vary and a site builders tolerance or requirements can vary about the minimum allowed stability.
For example, some organizations don't allow anther other than stable modules in production, while others are fine with being on the bleeding edge with alpha quality modules.
With core, the experimental module process results in non-stable code being in branches, and contrib stability can vary wildly.
Right now, the stability is manually enforced by the site builder.
Proposed resolution
1. Introduce a new $setting:
$settings['min_module_stability'] = 'stable'; // or 'beta', 'alpha', 'dev'.
For BC, default it to 'dev'.
2. Extended the .info.yml schema to add an optional stability key; mark all core current non-experimental module as 'stable' and experiementals to their current state.
Remaining tasks
Discuss edge cases and impact on contrib.
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|
Comments
Comment #2
catchWe can (have to) default this to dev, but we could also potentially set it to stable or beta for new installs by writing it to settings.php in the installer.
Comment #3
SKAUGHT#2870295: Concerns about beta and RC contrib without security coverage
Is this not suppose to be for the notice you get while activation modules, not actually 'allowed to install'? Also the (notice) message seen should reflect that 'min_module_stability' setting.
issue title should reworked. "..allowed before Activation Notice would be shown"
Comment #4
mpdonadio#3, this idea is a little different. With this setting, this would prevent modules from ever showing up in the list. So, if it is set to 'stable', you wouldn't see the experimentals in the UI at all and you couldn't enable them. This would be similar to how the
$settings['extension_discovery_scan_tests']works; that defaults to FALSE, but if I set it to TRUE, I can install the core test modules.Comment #5
pfrenssenWhat is the intended use case? Site builders / site owners that can log in to a running Drupal site with an account that has permissions to enable modules, but having no access to the file system?
That seems like a very limited use case, because if you can control the setting, then you can also control which modules are available on the website.
So in practice this would boil down to being a setting that will allow or prevent users from enabling the core experimental modules. Or maybe some optional alpha / beta modules that are included in distributions but not enabled by default.
I think this is not going to be useful for a large number of users. If you don't trust your site builders in their ability to enable modules they should not enable, then either don't give them the permission to enable modules, or simply make sure that disallowed modules are not present in the codebase.