Thomas Heigl

@investr777: Thanks for the detailed report and sorry for the late answer! The `RecordSerializer` currently does not have support for backwards/forwards compatibility. It is a limitation in its design that...

@investr777: Yes, my goal is that Kryo 6 is backwards compatible (See https://github.com/EsotericSoftware/kryo/wiki/Kryo-v6-Ideas).

What is your use-case for changing the reference flag on the fly? Could you work around this limitation by switching between two separate Kryo instances instead of changing the flag?

Ok thanks for clarifying. Please continue using two separate instances. It would be rather difficult to reset the cached fields of all field serializers when the flag changes. I think...

Hi @chrisr3. Do you need this change for your custom serializer registration to work, or is this just something that would be nice to have? Would overriding `register` be enough...

I mean something like this: ```java public class MyClassResolver extends DefaultClassResolver { @Override public Registration register(Registration registration) { return super.register(adapt(registration)); } private Registration adapt(Registration registration) { // modify registration here...

Do you have full control over the Kryo instance? Or can it be changed by clients/users? If you have full control, then using a custom class resolver isn't really an...

@chrisr3: I gave your issue more thought over the weekend: Even if I were to merge this change, you would still need a lot of complex code to achieve your...

> To be fair, I never intended to add my CollectionSerializerAdapter to this PR. I was simply looking to create an "officially supported" method of intercepting the creation of new...

Regarding your PR: I'm not really happy about going from Kryo to DefaultClassResolver and then calling back into Kryo. And since these classes are in different packages, this means that...