Drupal 8 was released almost two years ago, and it embodied a reexamination of the CMS. With that shift came the introduction of experimental modules. The purpose of experimental modules is to let contributors test new features in Drupal 8 core and receive feedback in minor releases without having to conform to the typical production requirements. Though the modules, as the name implies, are experimental, they do have to meet some minimum requirements and are processed through separate stability levels from core, which are outlined below. Experimental modules are included in the Core (Experimental) package on the Extend page of a Drupal site and they are not fully supported.
WHEN TO USE DRUPAL 8 EXPERIMENTAL MODULES
Experimental modules are a good option to test new features in a quicker and less cumbersome manner but if not used correctly, you could end up wasting time. Choose to use experimental modules in instances where your feature will require multiple issues to get to stable functionality or if getting there would be disruptive. Another tip is to open an Idea issue and get feedback from product and framework managers to see how initiatives are chosen and approved.
BRIEF DEFINITION OF STABILITY LEVELS
Drupal.org has outlined the four stability levels for experimental modules that are outside of the Drupal core release that contains them.
· Alpha – Alpha experimental modules are still under development, but available for initial testing. They may include bugs, including security or data integrity issues.
· Beta – Beta experimental modules are considered API- and feature-complete for the minimum viable product. Some early adopters may begin using beta experimental modules on development sites, but should be aware that they are not yet fully supported and may contain bugs.
· Release candidate (RC) experimental modules are essentially stable and may be release-ready, although some changes might be made to address critical bugs.
· Once an experimental module is judged stable, the module will be moved out of the Core (Experimental) package and its version number and allowed changes will be the same as Drupal 8′s core. Experimental modules may only become stable modules in minor or major releases.
CURRENT EXPERIMENTAL MODULES IN DRUPAL CORE
There are a variety of experimental modules currently in core at various stability levels:
Migrate Suite/Stability
Migrate – Beta
Migrate Drupal – Alpha
Migrate UI – Alpha
Workflow Suite
Workflows – Stable for V. 8.4.0
Content Moderation – Beta
Layout Suite
Layout Discovery – Stable for V. 8.4.0
Field Layout – Alpha
Media Suite
Media – Stable for V. 8.4.0 (Hidden, pending better UX)
Other Features
Inline Form Errors – Stable for V. 8.4.0
Place Blocks – Alpha
Settings Tray – Beta
DateTime Range – Stable for V. 8.4.0
MINIMUM REQUIREMENTS FOR EXPERIMENTAL MODULES
Experimental modules can have some outstanding issues however, they must meet the minimal requirements as outlined below on Drupal.org:
· No known security or data integrity issues.
· No disruption or regression to stable functionality (including being able to remove the experimental module without lasting disruption).
· Functional test coverage for the primary usecase, with no test failures in HEAD.
· Basic API documentation for the minimum requirements, an initial change record draft for the addition of the module, and a plan for completing more comprehensive documentation in the codebase and handbook.
· Ideas/prototypes for user interfaces that are planned and minimally validated.
· Wherever possible, extension names, namespaces, plugin IDs, etc. should be valid and match the intended final names, to avoid unnecessary upgrade path issues. (This includes whether it makes sense for the functionality to exist in a separate module at all.)
· Resolution of other critical issues that maintainers identify as hard blockers.
· A separate module roadmap (“plan” issue) documenting follow-up steps for outstanding work, including:
· Follow-ups to meet the core gates.
· Follow-ups to address concerns with the experimental UI and architecture, and iterate on them as needed.
· Any other issues identified during planning and review.
· A timeframe for completing the remaining work (typically two minor releases), a plan for addressing follow-ups, and roughly which follow-ups must be completed to keep the module in core. Follow-ups should be grouped according to whether they must, should, or could be a part of the module’s initial stable release.
There it is: An overview of experimental modules. Given that your features fit the profile and that you prepare and then play by the rules, this can be a bonus for Drupal 8 developers and for the CMS itself. To stay up-to-date on experimental modules, visit drupal.org.
Source: Drupal.org, Updated September 18, 2017