Mark SDC as beta so it can be included in 10.1

I think this issue will need to have the release stuff attached to it.

Added some related issues.

The main constraints for a beta release are that it has to provide backwards compatibility and data upgrade paths. Upgrade paths aren't relevant here so it's whether there are likely to be changes requiring bc. Since SDC is designed for contrib modules and themes to rely on I can see the advantage of a long beta phase in 10.1/10.2

Yes, I understand the implications of being in beta phase.

I think that between maintenance of CL Components, the discussions in the issue queue, and the extensive validation and testing of the UI Suite team, I feel good about the API. Besides, the API surface is quite small. It is mainly a render element, a metadata file, and a folder structure convention, so it won't be super hard to add BC layers if necessary.

1. I'm ashamed to admit I don't already know the answer to this, but where exactly do we "mark" experimental modules as either "alpha" or "beta"? 😅 There's nothing in sdc.info.yml to indicate this. All we get is lifecycle: experimental to handle the experimental part. But is the alpha vs. beta designation visible anywhere in core? Or does this only live in the minds of the release managers, and they have to manually deal with this on every release or something?
2. Semi-related: I now realize we didn't add anyone/anything to MAINTAINERS.txt when SDC went into core. Is the idea that since this is going to stop being its own module once it's stable that there's no new "subsystem" as such?

Thanks/sorry,
-Derek

I am also ignorant about #7.1.

I believe the rationale in #7.2 is correct.

#7.1 Experimental modules and their stability are documented in https://www.drupal.org/about/core/policies/core-change-policies/experime... → . Modules that haven't reached beta stability are removed from the actual tagged releases, meaning that most users would not interact with alpha experimental modules.

I guess I am wondering more about how is it marked as beta, rather than why. In other words, is this issue going to result in a patch adding the word beta anywhere? Or is it just a mental note for the release manager not to strip SDC when tagging the release?

@e0ipso atm the only place this is documented is in the table on https://www.drupal.org/about/core/policies/core-change-policies/experime... → - so if we decide to say that sdc is beta then when we release 10.1.0-alpha1 we'll update that table and say it is beta, otherwise we'll remove the module from the release and update the table and say it is alpha :)

If all the blockers for beta have been marked as fixed in the queue and there's nothing outstanding in the laboratory module queue - https://www.drupal.org/project/issues/sdc?categories=All → the next steps are:

• Add a change record to detail that the beta module is available and contain links on how to use it and to the future plans
• Add a release note to the issue summary here so it can be included in the release highlights etc...

@e0ipso atm the only place this is documented is in the table on https://www.drupal.org/about/core/policies/core-change-policies/experime → ...

Got it! I was not aware of that table.

If all the blockers for beta have been marked as fixed in the queue and there's nothing outstanding in the laboratory module queue - https://www.drupal.org/project/issues/sdc?categories=All →

I can confirm everything is good in that regard.

Add a change record to detail that the beta module is available and contain links on how to use it and to the future plans

Can I add it? Or is this something the release manager typically does? I will try to take a stab at redacting it in this issue, so I can get feedback on it. Sounds good?

Add a release note to the issue summary here so it can be included in the release highlights etc...

On it!

We should add a core component for SDC, unless it's going to stay under render system?

Also should probably move issues from the module to core now?

Big step in beta stability is triaging the existing issues and ensuring there's no bonus beta blockers in the queue.

We should add a core component for SDC, unless it's going to stay under render system?

I think we can go without. The plan is to sprinkle the code over core for stable, so there won't be a module. I think render system captures the component well.

Also should probably move issues from the module to core now?

Big step in beta stability is triaging the existing issues and ensuring there's no bonus beta blockers in the queue.

Will do. I think most open things are discussions that ended up resolving in the MR issue.

@catch I triaged the issue queue in https://www.drupal.org/project/sdc → and I confirmed there are no beta blockers. In fact only four issues were moved to core, two fixed, and one of them is postponed for more info.

• ✨ Have a way to implement the a preprocess function per each SDC component (ideally in the same folder) Active
• ✨ Allow union and intersection types for SDC object properties, just like PHP does Active
• ✨ Allow different methods of discovery for SDC components Fixed
• 🐛 Add alter hook and cache backend to component plugin manager for SDC Fixed

Updating issue summary to add release note.

Change record added at https://www.drupal.org/node/3355112 →

Marking as RTBC as [my understanding is] SDC is ready to be marked as beta.

Minor nitpick edit in the release notes snippet.

I think this is one where a long beta is more useful than a long alpha since we actively want contrib building on the beta code and there is no data to worry about. I didn't review all the outstanding issues yet though.

I looked at 📌 If needed, create automated tests to validate SDC's use of Drupal escaping and Twig sandboxing Active and briefly discussed with @alexpott. Since SDC is piggybacking on twig nothing can go wrong unless it actively undermines twig sanitization. So it's good to enforce that with tests prior to stable but agreed it doesn't seem beta blocking at all.

From FEFMs the assumption was that SDC would go in as beta immediately. We met a few weeks ago to triage the issues and went through all of the considerations related to marking it as beta such as making sure which APIs we think should be internal. This was documented in #3340712-129: Add Single Directory Components as a new experimental module → .

Updated IS to feature #21.

#3354860-21: Mark SDC as beta so it can be included in 10.1 → is exactly what I was asking for in #13, didn't realise that level of triage had already been done. We'll need another round prior to stable for issues that might come up in the meantime but that's good for untagging for RM review for me.

Tagging.

I updated the list of experimental projects to note Single Directory Components as beta.

With https://www.drupal.org/about/core/policies/core-change-policies/experime... → listing this module as beta, what else is needed to mark this issue closed?

That's it, thank you 😀

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