Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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
- https://www.drupal.org/core/experimental contains an initial draft of a handbook page on experimental modules, based on core committer brainstorms. This page needs review and signoff.
- Update and link related docs:
Incorporate more details about uninstall/reinstall/upgrade paths.DoneClarify more that unstable and alpha are not subject to the allowed changes policy and can change internal APIs.Done
Comments
Comment #2
xjmCouple topics that are missing from the page are:
We should also reference (and update) these docs:
Comment #3
xjmComment #4
xjmComment #5
xjmComment #6
xjmAlso added: https://www.drupal.org/core/d8-allowed-changes#experimental
Comment #7
xjmComment #8
xjmComment #9
yoroy CreditAttribution: yoroy commentedQuick 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
Comment #10
xjm@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.
Comment #11
yoroy CreditAttribution: yoroy commentedThanks! Forgot to mention that I was mostly quoting nod_ but I think I understand what you're saying :)
Comment #12
xjmDries 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.
Comment #13
catchJust to confirm this looks great to me.
Comment #14
xjmThanks @catch!
Comment #15
catchThere'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.
Comment #16
xjmYeah, 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.
Comment #17
xjmAdded: https://www.drupal.org/node/2657056/revisions/view/9322518/9367864
Comment #18
Dries CreditAttribution: Dries commentedThis looks good to me! Thanks @xjm!