Being tied to a specific version of a dependency, and esp. one that is not-[actually-long-term]critical, sounds like a problem. It doesn't seem like Avro needs to be in core. I am in favor of about any path someone wants to address towards removing that from core [ *#2 in the design doc seems reasonable* ].
Naturally, having ways to more easily change versions [esp. to remediate CVEs, but for any specific reason ], seems very valuable. It reads as a significant problem; I wouldn't take issue with a breaking [ compile time ] change, if that got things addressed and somewhat straightforwardly - *I am concerned of what could go wrong for users in the in-between/transition state while more slowly transitioning avro to extension.* On Wed, Nov 9, 2022 at 5:43 AM Alexey Romanenko <aromanenko....@gmail.com> wrote: > Any thoughts on this? For now, we'd need to decide which path finally to > take to move forward. > > Thanks in advance! > > — > Alexey > > On 4 Nov 2022, at 16:44, Alexey Romanenko <aromanenko....@gmail.com> > wrote: > > Hi all, > > Following-up an Avro dependency update discussion [1] that showed a lot of > uncertainties to move forward, Moritz and I decided to create a design > document [2] with potential options, that we believe, can be considered and > used further. Unfortunately, all solutions lead to breaking changes in some > way, though, for some of them the negative effect can be reduced by > preparing users for this in advance and make this transition smoother. > > Please, take a look on this doc and leave your comments and opinions - > your feedback is very welcomed! > > [1] https://lists.apache.org/thread/mz8hvz8dwhd0tzmv2lyobhlz7gtg4gq7 > [2] > https://docs.google.com/document/d/1tKIyTk_-HhkmVuJsxvWP5eTELESpCBe_Vmb1nJ3Ia34/edit?usp=sharing > > — > Alexey > > >
