[policy, no patch] Can we (and to what extent) make changes to experimental profiles during a patch release?

So where this is tricky. Using the field name example, if we have specific theming around the field name, then that would also get updated for the new field name. Existing sites with the old field name would 'lose' the theming and get a visual regression.

If you install 8.5.0 on Monday, 8.5.1 is released on Wednesday and you immediately update, then your demo site is 'broken' - but you might not be done evaluating in two days by any means.

However if we don't backport those changes, then it's harder to get Umami improvements into patch releases, and there'll be greater code divergence between branches.

My preference is to backport changes as much as possible, since updating a demo site should be an edge case, but it also makes me think about affordances that make it easier to blow away and re-install (like a big red button somewhere that empties the db and redirects to the installer).

Also @alexpott said that maybe a check as to whether you are still on the exact core version you installed Drupal with (in this profile) could show up a warning telling you to reinstall to continue the evaluation. Obviously if you have been messing around, that would be blown away.

So where this is tricky. Using the field name example, if we have specific theming around the field name, then that would also get updated for the new field name. Existing sites with the old field name would 'lose' the theming and get a visual regression.

I've thought about the theme breaking issue (as that is probably the most likely place for a break, due to preprocessing etc.).

Absolute worst case, we could have a drupal.org project page for the theme, where people can download the specific version for a core release should there be a BC break / fatal error. Another option is for a user to copy the theme to their /themes/custom folder, but that would only be possible if they could roll back from their upgrade if there was a break.

Also @alexpott said that maybe a check as to whether you are still on the exact core version you installed Drupal with (in this profile) could show up a warning telling you to reinstall to continue the evaluation. Obviously if you have been messing around, that would be blown away.

This warning was on the status report in our initial version. This has been discussed, and since removed - but we could bring it back if needed. See #2938805: Finalise the wording of the warning message on the status report page

Another option is for a user to copy the theme to their /themes/custom folder, but that would only be possible if they could roll back from their upgrade if there was a break.

Although that should in practice be possible for a patch release, we can and do add updates to patch releases, so it might not always be possible to roll back. It's also something that could be tricky for users to do - especially if they're using a hosting service that upgrades core for them.

I'm not sure how realistic it is that someone would update core for a demo install - people don't always update promptly for real sites even, so it's partly a question of are we prepared to take a bit of flack if someone does run into this, vs. getting changes available quicker for everyone installing new demos - I'd still lean towards the latter and we could always tighten things up later on if it turns out to be a real problem.

I'm not sure how realistic it is that someone would update core for a demo install - people don't always update promptly for real sites even, so it's partly a question of are we prepared to take a bit of flack if someone does run into this, vs. getting changes available quicker for everyone installing new demos - I'd still lean towards the latter

+1 for leaning towards the latter.

We raise warnings in multiple places telling people this is just for demonstration purposes. Whilst we could expend effort in allowing upgrades, there is an inevitable opportunity cost; that being the quality and feature set of the demo evolving going forward. I can't see how it is possible to justify effort on the non-intended use at the expense of the actual intended use.

My preference is to backport changes as much as possible, since updating a demo site should be an edge case, but it also makes me think about affordances that make it easier to blow away and re-install (like a big red button somewhere that empties the db and redirects to the installer).

Yes to that.

In Drupal 7, my employer maintained an install profile with a BC promise - aGov

It was a nightmare to ship updates to installed features etc.

For most sites we built of it, as soon as we wanted to change a view/field/content type - we ended up forking the feature that provided it and switching off the feature from the profile.

With Drupal 8 and each site owning the configuration, it is much easier.

In line with that, aGov on D8 doesn't do backwards compatibility, once you install, your site owns the config. If we add a new feature, you may not get it. Eg. the default admin view for content is changed to add content moderation integration. If you installed before that, your view won't include it when you upgrade. We really only provide module/security updates and new features that are standalone.

So where this is tricky. Using the field name example, if we have specific theming around the field name, then that would also get updated for the new field name. Existing sites with the old field name would 'lose' the theming and get a visual regression.

I think a visual regression is tolerable (not ideal) but a fatal error because a theme-preprocess or theme-suggestion-alter hook is doing $entity->{some_field_that_may_not_exist}->entity->label() is not.

So we should make sure we have guards there, e.g. $entity->hasField('some_field_name') exists, and should be used.

So we should make sure we have guards there, e.g. $entity->hasField('some_field_name') exists, and should be used.

Yep. And that makes sense anyway because when trying out the demo you have access to the field UI and could delete the field.

So we should make sure we have guards there, e.g. $entity->hasField('some_field_name') exists, and should be used.

This is true, but potentially tricky - for example we have a standard image field at the moment for promoted images, but one day this will change to be media [hopefully!]. Another thing is the user could remove that field, and create another field type with the same name. Or change from a maximum of 1 value to unlimited. There's a lot of edge cases we might need to start handling.

I guess a check for the field, and is it the type we expect should be ok - that way if things change we should just fall back to a visual regression rather than fatal errors (which agreed, is definitely what we want to avoid).

We're hoping layout builder will help with reducing the need to preprocess etc. when it lands :)

In #2944113: [policy, no patch] Should Umami/OOTB support backwards compatibility and an offical upgrade path from one version to another? @catch pointed out we are discussing this at two places. Let's close this one in favor of that one (which I also hope to close).