I understand that it was quite unfortunate that we forgot to remove the nullability of the argument after having deprecated passing null. However, this change is problematic:

• Right now, it is possible to create the object without passing a workflow or setting it to null. You would break that functionality. Then again, actually setting the workflow to null would break getWorkflow(), getWorkflowName() and getMetadata().
• This change will trigger a warning on PHP 8 because $workflow is mandatory now although it follows an optional parameter $transition.
• The parameter $transition is effectively mandatory as well now which is a BC break.

Oops, I merged too fast, now reverted. Please submit again @lyrixx

Oups, good point !
So we need another round of deprecation ? we need to re-swap all arguments ? 😨

Looks like it. 😢

Or maybe just turning Transition into a mandatory nullable argument rather than swapping.

anyway, I don't expect this constructor to be used a lot in third-party code. This code is expected to listen to events, not to trigger them.

Or maybe just turning Transition into a mandatory nullable argument rather than swapping.

Not possible, some events are not directly related to transition

Not possible, some events are not directly related to transition

Those events would eplicity pass null as transition then.

anyway, I don't expect this constructor to be used a lot in third-party code. This code is expected to listen to events, not to trigger them.

Me neither. This would mostly affect third party code that extends the workflow component with own logic. But since neither the Event class nor its constructor is flagged as @internal, calling the constructor in third-party code is valid.

but for that code, marking the argument as required or swapping arguments is a BC break in both cases