Undocumented (BC) serialization of UuidV4

[simonberger]

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	yes
RFC?	no

In case I do not miss anything #887 added a forced serialization of all Symfony\Component\Uid\AbstractUid classes which has been added in version 4.2.0 already.
The affect is to end with a string instead of a stdclass(uuid:) which should be considered a breaking change.

For me this is not very bad right now as I am updating from version 3 to version 5 directly and noticed an error due to an unexpected result from an API in the implementation phase.
Yet I could not find anything in this regard in the upgrade notes (beside the mentioned change in a minor release). Additionally I would want to deactivate this handler for now and the only way to do this is to remove the handler from the container or to add an own one for the classes and do actually nothing there?

I wonder why I seem to be the only one with such an issue and therefor might miss something, but I couldn't figure out what this might be.

[mbabker]

This is a weird case as technically adding any new handler could cause a serialization break for a downstream user. But, without bloating the configuration and making every handler opt-in, I don't know if there's a great way to avoid this type of issue.

[simonberger]

@mbabker Imo adding a new handler via opt-in in a minor release and change it to opt-out in the next major release (if this is the intention) would be the way to go. ATM opting out is not even possible.
The uuid handler had been released with opt-in with 4.2.0 which is bad. The only explanation for my why there were no bug reports is, that there simply were no use cases of serialized uuid objects or interpretation of this result.
The 4.2.0 release is history but for the current state I have two improvement suggestions:

• The missing upgrade notes entry
• Not being able to even opt-out of this handler (without hacks like removing it from the container or adding a higher priority own one)