Revamp the Avro entrypoint completely to reduce the complexity and improve extensibility. Example: Json class in kotlinx serialization. See #163
More extensible serialization (allow bytes headers for custom format wrappers like confluent schema registry, or the other avro file standards like single object)
✅ #162
Replace AvroDescriptor by a @CustomSchemaGenerator(MyCustomGenerator::class) for allowing generating custom schemas without using reflection, also usable with custom serializers. See #175 #162
Caching of schema and other internal processes (record & field namings, aliases, ...). See #159
Replace AvroName and AvroNamespace by just SerialName, natively working with kotlinx. See #165
Also improve naming strategy #178
Reduce the dependencies to the minimum and set some as optional. See #149
Allow more types for the map key. See #114 #131
Better contribution guidelines, with semantics checks and more complete code formatter in .editorconfig
Handle all the possible schemas as root schema, and not only records. See #80
Non goals
kotlin multiplatform, as it needs to implement everything ourselves instead of just using the apache avro java library. But still, it'll be taken into account in the new Avro entrypoint design for better extensibility.
Direct encoding: Same as the previous line, since we would have a better extensibility, selecting different mode of serialization should be easily done, like also writing into json
Keeping all the exact same features: By example, AvroName and AvroNamespace will be changed to the native single annotation SerialName
Maybe ?
141 (maybe, as if we succeed of revamping the Avro entrypoint, we could more easily use the apache avro library standard encoders like single object, json, and more)
158 (maybe, because it's not really mandatory, as we currently have the workaround of json)
Bug fixes
Improvements
Avroentrypoint completely to reduce the complexity and improve extensibility. Example: Json class in kotlinx serialization. See #163@CustomSchemaGenerator(MyCustomGenerator::class)for allowing generating custom schemas without using reflection, also usable with custom serializers. See #175 #162AvroNameandAvroNamespaceby justSerialName, natively working with kotlinx. See #165.editorconfigNew features
Non goals
Avroentrypoint design for better extensibility.SerialNameMaybe ?
141 (maybe, as if we succeed of revamping the Avro entrypoint, we could more easily use the apache avro library standard encoders like single object, json, and more)
158 (maybe, because it's not really mandatory, as we currently have the workaround of json)