Should we ask this user to contribute

[civic merlin]

Feature-wise this looks pretty great. If @bold cove's on board then I'm sure @hardy herald and I would be happy to work with the contributor from the product and UX side of things

[bold cove]

Honestly, a quick glance at it; this thing doesn't solve the problem why we decided not to do update entities on blueprints.
Blueprints can break automations on update; the goal we set was to have migration/update paths from a->b. This integration doesn't provide that?
Additionally, I think we need to bundle the blueprint in the automation, so we are not breaking 10x automations by updating a single blueprint potentially

so I'm not fully understanding what is different?

[hardy herald]

I do agree with Frenck that updating blueprints has a great chance to break stuff, and it should be a very hands-on experience, rather than something that is automated (even with safe guards).

[civic merlin]

Maybe I'm missing something, but isn't at least part of what this user implemented very interesting to get into core? It's not all or nothing right?

[vestal hatch]

Having an update entity informing about a new version of the blueprint could still be useful, even without the updating part.

[jovial dirge]

So there are different parts.

One part is something that I discussed with Frenck in the past, and that's that to handle breaking changes better, we would want to be able to update the version of the blueprint per automation. So if there is a breaking change, you're not forced to update all or nothing.

Now when I said contribute this to core, I didn't mean copy 1:1. But here is a user that a) is excited about updating blueprints (yay!) and b) is working on a solution that is partially there.

maybe update entities is not the right thing indeed, and more like a "wizard" style, where you navigate your blueprint update, pick which version to update it to.

I am afraid that we are getting too paralyzed by the edge cases of breaking changes.

If we think that an update entity per automation for blueprint is the way to go, with per-automation blueprint updates, happy to open an architecture issue to move this forward.

[civic merlin]

I agree. There's some good ideas in here. Would love to work with the user to shape it into something that we could get into core

[jovial dirge]

could work something like this.

[hardy herald]

Yes, this would be a right way going about it. One question remains about if we want to have just one version of a blueprint available to update and thus update automations that are based on it, or we (as Frenck said) bundle the blueprint in the automations and update that per 'bundle'

So you could have automations that use the old blueprint, and maybe create new ones with the newer blueprint

[civic merlin]

Aren't users automatically "forced" into this situation if they choose to update some automations but not all?

[hardy herald]

Updating blueprints work by re-importing it. So if you do that all of the automations using them will be updated and may break. AFAIK you cannot use different versions of the same blueprint at once.

[jovial dirge]

my only concern with this is that it's going to be absolute chaos and people lose overview, running around with 4 different versions of a blueprint etc, UX nightmare.

After sleeping on it I personally lean to not solving this problem. Instead, we do not allow blueprints to have breaking changes in their inputs. If a blueprint is going to want to change the way it behaves, just like in Go, it should just pick a different name (like adding a 2 or so)

If people want to make breaking changes, they just can't use our update system

[civic merlin]

So we need to decide what changes in blueprints we consider breaking. Is adding a new input breaking if it's optional? Probably not, right? Is a blueprint changing its actions so it works differently breaking? From the end user perspective: maybe. But from a migration standpoint: probably not. And so on and so forth

But we can do all that if we decide that we want to work with this user to get some of what he built into core