[policy, no patch] At what points should the umami demo be marked as stable?

Tagging :)

After you can show an Umami site still functions after a core update? If Umami can't run without error after updating Drupal from 8.5.0 to 8.6.0, all this is really demonstrating is that D8 updates are difficult and prone to errors even for developers very familiar with Drupal.

@kreynen: why would you update an old demo site? what is the use case?

As someone who evaluates CMSes and other services, how updates to the product or service are handled is one of the things we evaluate.

I like the fact that someone can spin up a fully populated D8 demo on non-drupal centric host like https://azure.microsoft.com/en-us/campaigns/cms/ or a local docker configuration because the demo was included in core, but the idea that everyone who installs a demo makes a decision before applying updates isn't accurate. A completely disposable, un-updatable demo might work for someone evaluating frameworks for small, personal sites, but in my world we spin up demos of several competing frameworks or services. Someone takes the lead on spinning up an instance of each option, then we have a series of meetings where the lead for each service/framework that's being evaluated shows off what they liked and didn't like about the service/framework.

A D8 install using Umami would definitely give Drupal an advantage in this type of evaluation. It will also score well because it provides a visual view of required updates. On most Drupal centric hosts like Acquia or Pantheon, required or recommended updates also have a visual indicator in the site administration UI.

I can't imagine an evaluation where there is a visual indication of a required update and the update doesn't get applied.

The timeframe from someone configuring the demo to needing to showing off features of the demo to a larger group can be weeks. Any service or framework that blows up its own demo when updates are applied is very unlikely to get selected.

The question will be, "If the framework/service's own development team can't maintain a demo that allows updates to be applied, what is going to happen to my organization if we build similar functionality on this framework?"

This issue makes a lot of sense in terms of the overall release management goals of Umami, but seems like it'll take some time to get resolution on all of these questions. Because it's time-sensitive, I spun off #2957464: Un-hide Umami in 8.5 to vastly improve Drupal's evaluator experience to talk about the first one of these (un-hiding the theme in 8.5) explicitly.

If anyone has thoughts on BC, please add your comments to this issue #2944113: [policy, no patch] Should Umami/OOTB support backwards compatibility and an offical upgrade path from one version to another? so we can collate them all in one place.

This issue packs various questions in one (probably too much). Unhidden, beta and stable are potentially three different things. At last we reached a state where release management feedback indicates we are ready to unhide the profile in 8.5 (and keep it unhidden in 8.6). See #2957464: Un-hide Umami in 8.5 to vastly improve Drupal's evaluator experience.

I think we either need to repurpose this issue to talk about making it stable (if the team wants to do that anytime soon) or close it (if not). My understanding was being stable is not an goal anytime soon given that would not allow to change to support new core features, so I think this issue should be closed.