Drupal 8.2 get experimental
Drupal 8 core introduces the concept of experimental modules. These are modules that are provided with Drupal core for testing purposes, but that are not yet fully supported.
What is the purpose of experimental modules?
Since the release of Drupal 8 in November 2015, Drupal core has scheduled minor releases every six months. Experimental modules, which can include new functionality or expand on existing features, allow developers who work on Drupal core elements to develop functionality quickly and efficiently that may then be supported by a scheduled minor release. These developers receive feedback from the user community, and can use that information to speed the development along without having to adhere to the more intense, prolonged requirements necessary for major versions of Drupal, like the move from 7 to 8.
Are these modules ready to be used?
That answer varies. Experimental modules can be labeled Alpha, Beta, Release candidate, or Stable core module. The Drupal community defines each in this way:
- Alpha experimental modules are still under development, but available for initial testing. They may include bugs, including security or data integrity issues.
- Alpha modules are not subject to the restrictions on allowed changes and may have backwards compatibility (BC) breaks even between patch releases. Developers should not rely on their APIs.
- No upgrade path is provided from alpha versions. To resolve issues for the module, uninstall and reinstall it (backing up any data).
- Beta experimental modules are considered API- and feature-complete. 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.
- Developers can begin using beta modules' APIs, but should be aware that some things may still change to address bugs. Beta modules are subject to the beta allowed changes policy.
- An upgrade path may be provided from beta versions, but be aware it may contain critical bugs.
- Release candidate (RC) experimental modules are essentially stable and may be release-ready, although some changes might be made to address critical bugs.
- RC modules are subject to the RC allowed changes policy.
- Upgrade paths are provided from release candidate versions.
Stable core module:
- 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 core's. Experimental modules may only become stable modules in minor or major releases. Not all experimental modules will necessarily become stable core modules.
What do experimental modules mean for SiteFarmers?
The experimental modules included in a minor release continue to be worked on by members of the Drupal community. As ones of interest to our audience reach at least a Beta level of stability, the SiteFarm team will open up the option for site managers to activate these approved modules in their own sites for experimentation and integration.
Which experimental modules will we see soon in 8.2.0?
Place Block (alpha stability)
This new 8.2.x feature allows the user to place a block on any page and see the region where it will be displayed, without having to navigate to a backend administration form.
Settings Tray (machine name: outside_in, alpha stability)
This is a prototype of Dries's proposed Outside-In usability enhancements, which allow configuring page elements such as blocks from the front-end of your site.
Content Moderation (alpha stability)
This new experimental feature allows defining content workflow states such as Draft, Archived, and Published as well as which roles have the ability to move content between one state and another.
Datetime Range (alpha stability) - INCLUDED NOW IN BETA 1's EVENT PAGE CONTENT TYPE
The experimental DateTime Range module provides a new field type that allows end dates. This is important for helping contributed modules like the Calendar module to work with Drupal 8 core. There are some small presentational, usability, accessibility, and translatability issues with the field, and its API may be refactored somewhat as we improve both it and the stable DateTime module. However, the data model for the field has consensus, so contrib and site authors can begin working with the module so long as they are willing to manage the risks of using an alpha experimental module. You can read the DateTime Range module plan for the next steps to make this useful field a part of the Standard installation.