Decide on approach to use for storing past revisions of XB config entities

Workspaces should allow to revert a workspace after it has been published. Unfortunately this is currently broken for wse_config but it could be fixed.

From the issue summary it feels that you are expecting reverts to take place outside of a workspace - I think we should update the issue summary with a user journey that explains how and why a user would want a revert capability.

Workspaces should allow to revert a workspace after it has been published.

Is there a time limit or number of published workspaces limit to this? I think the typical flow we'd want to support is:
- An editor makes changes to content+config, then publishes it.
- An editor makes changes to content+config, then publishes it.
- An editor makes changes to content+config, then publishes it.
... repeat N times.

Can the editor now go back and view any prior published state and revert to it? Does the answer depend on whether this is all done in a single "review" workspace that sticks around after publishing vs. if the workspace gets removed after publishing and a new workspace is created for the next round of changes?

Precisely because options 1 and 2 involve additional contrib modules with limited real-world adoption. we worked on a PoC in the early XB times to ensure that we were confident that there was a way to do this.

See the research__design_versions PoC I did 8 months ago, which relies on config overrides.

@effulgentsia: Where do you see that fit in your issue summary? I suspect it's option 3?

@alexpott: What do you think about it? If you could spend a few minutes looking at this commit, and perhaps especially ViewDesignLayoutVersionsTest, and share your high-level take on it, that'd likely be extremely valuable 🙏😊

See the research__design_versions PoC I did 8 months ago, which relies on config overrides. @effulgentsia: Where do you see that fit in your issue summary? I suspect it's option 3?

Yep, I think that's option 3, which is nice to have in our back pocket. Also, when you worked on that, we didn't know yet whether we'd be using Workspaces at all. But discussions since then are pointing strongly towards using it, so I think option 1 would be ideal if Workspaces actually supports the flow in comment #3.

🐛 Revert of a workspace containing configure changes does not work Active would need to get solved, even to make an immediate revert following publishing possible, but in addition to that, I'd still like to understand how Workspace handles viewing revision history and reverting over the long term, not just immediately after publishing.

I think using the config override system is a bit fraught for revisions because how it will interact with config translations which also use the override system. It's not a neat fit. On the other hand using config overrides at least makes the cache situation simpler because overrides are part of the config cache key.

A neat thing about using content entities to hold the future and past revisions of config is that we don't have to build a UI to manage that.

Workspace reverts were implemented in WSE with content in mind, config reverts haven't really been discussed nor tested that much, so they're pretty much a green field that can be changed in any direction needed by real-world use cases.

The design of workspace reverts in general is to allow users to revert workspace publications going back as far as possible, but only one at a time. For example, using the list of publications from #3, after the N workspace is published, then only that workspace can be reverted. If that happens, then the N-1 workspace publication can be reverted, and so on all the way up to the first publication.

In general, I get the feeling that wse_config is somehow seen as an immutable block of code, but it's really not.. it just happens to be the most experimental part of WSE, partly because it was a very hard problem to tackle, and partly because of lack of testing in multiple real-world scenarios.

About using config overrides for workspace-specific config, I've also been thinking about it for a long time, but, as confirmed by chatting with @alexpott a few days ago, that approach can't cover the use case of adding new config.

@effulgentsia in #6:

when you worked on that, we didn't know yet whether we'd be using Workspaces at all.

Indeed! It was a possibility. So what I did was meant to be possible to be used independent of the Workspaces module, but also be possible to be used with it. @alexpott spotted that too: see #3493461-17: Identify roadblocks to staging config in Workspaces (e.g., via wse_config) → and #7 😊

@alexpott in #7: RE: config translations. Damn!!!! 👏👏👏 That's a very good point, and one that I missed in the PoC I did 😔 XB's config entities definitely would need translations AFAICT: plenty of labels (for component instances, patterns, etc.) that ought to be translatable.

OTOH … any config in a workspace would need to be created in the default config language, to allow it to then be translated (and config translations to be loaded by LanguageConfigFactoryOverride), right? So … does that mean that any modifications to config in XB/workspaces must happen in that language? 🤔

@amateescu in #8:

About using config overrides for workspace-specific config, I've also been thinking about it for a long time, but, as confirmed by chatting with @alexpott a few days ago, that approach can't cover the use case of adding new config.

Damn!!!! 👏👏👏 That's a very good point, and another one that I missed in the PoC I did (see link in #4). 😬

[…] wse_config is somehow seen as an immutable block of code, but it's really not..

👏🙏 Thanks for stating this, this is a very important acknowledgement!

I read this as: "please feel free to expand upon what wse_config does, and/or take only the parts that y'all think are usable for the product requirements y'all have" — does that match your intent? 😊

The design of workspace reverts in general is to allow users to revert workspace publications going back as far as possible, but only one at a time,

I read this as: "reverting a workspace publication is like reverting git commits: if you don't revert them in the reverse order of how they were applied/committed, you'll likely run into problems because there will likely be conflicts, and if not conflicts, then there may be semantical problems" — is that a fair interpretation? 🤔