Problem/Motivation

Part of #2649768: [meta] No definition of "Experimental" & not nearly enough warning. Core includes experimental modules in 8.0.x, but there is no formal definition of what this means.

Proposed resolution

Create a handbook page that defines the policy for experimental modules: https://www.drupal.org/core/experimental

Some draft notes are in:
https://docs.google.com/document/d/1NZhyS3zSBc_EgBn4Cd_7LAHLCyDF__w8M86K...

Remaining tasks

Comments

xjm created an issue. See original summary.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Couple topics that are missing from the page are:

  • Highlight specifically that unstable and alpha are not subject to the allowed changes and BC policies.
  • Experimental modules may evolve even in patch releases, but only become stable in minors.
  • Even in patch releases, developers should expect that they may need to uninstall/reinstall the module to fix things, without any upgrade path or migration available for the data.
  • For beta, do we start providing best-effort upgrade paths as we did with core itself?

We should also reference (and update) these docs:

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes
xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes
xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes
xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Also added: https://www.drupal.org/core/d8-allowed-changes#experimental

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes
xjm’s picture

xjm
she/her
Primary language English
commented
Issue tags: +Needs product manager review, +Needs release manager review
yoroy’s picture

yoroy commented

Quick note from an IRC conversation with nod_ (without me reading the links in the issue summary, sorry): Would be good to be clear on an exit strategy for experimental modules. This was in context of discussing big UX changes:

- as a fix to the process I was thinking of more agressive timeboxing of ux isses. Since we get regular releases a bad ux change would be kept for 6 months at most
- that way if people don't like the new design/ux or have a bone to pick, they just need to wait 6 months for a chance to fix it. Not 4+ years

xjm’s picture

xjm
she/her
Primary language English
commented

@yoroy, actually, with this policy, "alpha" stability experimental modules could be changed if needed as quickly as every month, as well as "beta" stability modules if the issue were severe. So timeboxing is even safer because we can recover from mistakes without breaking our BC/stability policy for stable core.

yoroy’s picture

yoroy commented

Thanks! Forgot to mention that I was mostly quoting nod_ but I think I understand what you're saying :)

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Needs review » Reviewed & tested by the community

Dries has verbally signed off on this, and webchick said "that looks like what we discussed" but had not yet read over the specifics as of that point. Pinged @catch also awhile back.

I think this is an agreed direction, so promoting to RTBC to get the signoffs. We may need to update specific version numbers based on the outcome of #2656994: Experimental modules should have their own version numbers, but we can do that then.

catch’s picture

catch
he/him
Primary language English
commented

Just to confirm this looks great to me.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue tags: -Needs release manager review

Thanks @catch!

catch’s picture

catch
he/him
Primary language English
commented

There's one thing with yoroy's comment that I'm not sure is covered yet, which is how we actually remove experimental modules if we've given up on the experiment. But I don't think we need to have that to mark this fixed, same as it doesn't cover adding experimental modules in the first place.

xjm’s picture

xjm
she/her
Primary language English
commented

Yeah, I think part of preparing each minor beta is probably reviewing the experimental modules in core, and deciding what their status is. While the internal details of that probably aren't important to the audience of the handbook page, I guess we should at least state explicitly that they are not guaranteed to become full modules in the future. However, it's feasible to move them into contrib and let those who do want them maintain them there if needed.

xjm’s picture

xjm
she/her
Primary language English
commented

Added: https://www.drupal.org/node/2657056/revisions/view/9322518/9367864

dries’s picture

dries commented
Status: Reviewed & tested by the community » Fixed
Issue tags: -Needs product manager review

This looks good to me! Thanks @xjm!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.