Status

Current state: Under Discussion Discussion thread:

https://lists.apache.org/thread/4w36oof8dh28b9f593sgtk21o8qh8qx4

https://lists.apache.org/thread/t0bdkx1161rlbnsf06x0kswb05mch164

Vote thread: https://lists.apache.org/thread/0bh530j5ob11lzj48vpm883sqwgmstp8

JIRA: JIRA: here (<- link to https://issues.apache.org/jira/browse/FLINK-29844XXXX)

Released: 1.17

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

1. Existing UT of resolving compatibility could verify whether the old behavior could work as before.
2. Add extra UT to verify the correctness of customized serializer.
3. Add ITCase and e2e test case to mock the user behavior.

Rejected Alternatives

Introduce a new method in TypeSerializer

Compred to introducing a new method in TypeSerializer, we could get benefits if we introduce it in TypeSerializerSnapshot:

1. TypeSerializerSnapshot still owns the responsibility of resolving schema compatibility, TypeSerializer could just pay attention to its serialization and deserialization as before.
2. It's very convenient to implement it based on current implementation by all information in TypeSerializerSnapshot and tools which is also helpful for users to migrate their external serializer.

Introduce a method without default implementation

Why not:

We should make sure that user jobs still work without modifying any codes before removing the deprecated method.

So we need to have two steps to complete the migration and make sure that the first version will not break changeNone.