Yeah my point was whilst DASH-1282 is on that list, NOWHERE ON THAT TICKET did it mention you changed the behaviour of ==. it was all about ===. Just cos you changed it as part of that ticket, doesn’t mean we know that. So if you change something other than what exactly is on a ticket, you really ought to update the ticket to reflect that.

One should either do only what is on the ticket, or - if the scope changes (and fair enough) - also update the scope of the ticket to make that clear, eg “as part of this I have also changed how == works” (and that would need to go in the title as well, given it’s non-trivial). For all anyone else knew, the behaviour I reported could have been a bug that you unintentionally introduced.

NB: has sorted-out DASH-1242 now, and it’s perfect. It might be worth you checking what he has done as a benchmark for next time.

Good work on the other ticket and it’s appreciated. It’s just the comms that were wanting a bit here, but that’s also now sorted so: excellent!

all tickets with a breaking change are in this epic including this. for the Release candidate we will communicate this of course. maybe there is already a list for this, will know.

What you have done is absolutely fine given it was by design and not just a side-effect of the work in DASH-1282.

Is it documented anywhere that you have changed the behaviour of ==? I couldn’t find anything at the time, but that doesn’t mean much as == is not great to search for

Cheers for the feedback / clarification!

if you disagree we can discuss it and reopen the ticket.

we completely changed how this operator work, now it is compatible with the ACF behaviour including this case.

So a breaking change by design.