Mark Layout Discovery as a stable module

Given that DS and panels (and maybe others already too ?) have branches depending on layout discovery, the least disrupting way would just be to mark layout discovery as stable I think.

Also, give this:

+++ b/core/modules/system/system.layouts.yml
@@ -72,7 +72,7 @@ layout_threecol_33_34_33:
-  library: layout_discovery/threecol_33_34_33
+  library: system/drupal.layout.threecol_33_34_33

That would need an upgrade path no ? For DS, panels, Field layout, others to change the library ? Every module should have this then which becomes a bit tedious, I think.

So, I'm +1 on simply marking layout discovery as stable (but I'm fine with either decision).

Regarding library: good point, my fault. We should refactor this in DS because we store it (so we can unset it) .. will file a bug report for that :)

Interesting, this is both:

1. marking APIs as non-@internal
2. marking the module as stable (non-experimental)

But there are still a lot of open issues: 1 bug, 12 tasks, 3 feature requests at the moment. So that means you're confident that completing those tasks won't break any of the APIs? Things like #2834023: Discuss service ID and config schema naming for Layouts, #2846395: Increase module weight of field_layout, #2846393: [PP-1] Investigate alternative approaches to moving fields in FieldLayoutBuilder::buildView() and #2796877: Devise a mechanism for mapping old regions to new ones when moving between layouts look (at first sight) that they might cause or require BC breaks?

I'm asking this with the best intentions: I'd love to see more experimental modules become stable, but in being asked to maintain the REST module, I've seen the negative consequences of marking something as stable prematurely. Repeating those mistakes will cost us.

Should the HTML changes be separated from the API documentation changes?

Thanks @DamienMcKenna. In most cases, I'd say yes, but in this issue, both have to happen at the same time because both are required to mark the module stable, while neither can happen before the module is stable. :) In this case, the new templates are just copies of the templates that the module already provides (and have been reviewed already in #2852608: Review layout CSS and markup).

Is https://www.drupal.org/node/2619128 complete and up to date? That's docs gate for this.

@tim.plunkett pointed me to https://www.drupal.org/docs/8/api/layout-api which is the correct handbook page, so we need to update the hook_help() for this as well.

Bright future for layouts in Drupal, can't wait!

Updating the documentation link on hook_help (#18).

+1 one from me!

Looks good to panels! +1

+1 from me! Thanks everyone for all the hard work on this.

Thanks @swentel and @japerry!

Considering this for stable core inclusion:

• We have all the needed signoffs, including from Dries.
• The frontend and backened architecture has been reviewed and is stable.
• It meets the core testing, documentation, and performance gates.
• The accessibility and user facing gates are not relevant since the module does not provide user-facing functionality.
• Most of the "should-have" issues from the roadmap are complete.
• It's best for the ecosystem if this module is stable in 8.4.x and we only make BC additions in the future, since Panels already depends on it and is stable.

Based on all that, committed and pushed to 8.5.x and 8.4.x! Yay.

Thank you one and all!

👏🎉

This is fantastic for the project to have this. You'll have done an excellent job. Congratulations