Thus far, we've basically allows GraphSON and Gryo to evolve independently of one another. They have some common classes that they support for serialization but there are also some that are only supported by GraphSON or only supported by Gryo. Given the direction we're going with GLVs/bytecode, it would seem that choosing to not maintain feature parity going forward isn't a good idea. Now that GraphSON is lossless (with out option for serializing with "no types") it would seem confusing for GraphSON and Gryo to not support the same types.
As it stands, the gremlin-io-test module would work best with parity as the framework can easily share test code and read/write assertions that way. I have an exclusion mechanism which is nice but obviously we'd like to be able to test all the types and have them be validated from version to version in both GraphSON and Gryo. If we were to go the way of parity, it would mean that GraphSON would have to support a number of additional serializers (many of which would be in the GraphSONX module - extended feature set - i suppose). Either that or for Gryo 3.0 we drop support for certain types. It would mean that Gryo 3.0 would be further incompatible with Gryo 1.0, but since we will likely have some breaking change there, I suspect that is probably acceptable. Unless there are objections in the next 72 hours (Sunday, December 25, 2016, 12:15pm) I'll assume lazy consensus with the idea of feature parity for GraphSON and Gryo for the respective 3.0 in 3.3.0. I imagine there will be some separate discussion when it comes to determining what parity is (i.e. what types are ultimately supported).
