Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 291477

Experimental modules should have their own version numbers

$
0
0

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

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.


Viewing all articles
Browse latest Browse all 291477

Trending Articles