Problem/Motivation
- Drupal 8 core introduces the concept of "experimental modules" that are not completely production-ready but that are included in core for testing.
- Since these "experimental modules" are not considered stable and are not recommended for production use, it does not make sense to hold them to the same BC and patch release restrictions as stable code.
- Experimental modules should be able to iterate quickly in core.
- It should be clear to site builders and developers what state the experimental modules are in.
Proposed resolution
- Give experimental modules their own versions, separate from core, so that they can be in unstable, alpha, beta, or RC separately from core.
- Include these version numbers in the module's
info.yml
file and expose them on the Extend page. - The versions for these modules always begin with
8.y.x
in D8 while they are experimental, to make it clear that they are of lower stability than the rest of core and versioned separately from any particular patch or minor release. Examples:8.y.x-unstable
8.y.x-alpha
8.y.x-beta
8.y.x-rc
Optionally, we could designate specific multiple releases for the given stability in the future, e.g.
8.y.x-alpha3
, but for now the suffix only indicates the level of stability/allowed changes and not any particular release. migrate
is marked beta.migrate_drupal
is marked alpha.inline_form_errors
is marked unstable
Remaining tasks
- (followup) Consider highlighting the version number when it differs from core's and/or automatically extending the details on it.
- #2657062: [policy, no patch] Experimental module policy and handbook page
User interface changes
Experimental modules display a different version number on the Extend page.
API changes
Version numbers for experimental modules change.
Data model changes
None.