Personally, I think that keeping two mostly identical versions of Avro-related code in two different places (“core" and "extension") is rathe bad practice, especially, in case of need to fix some issues there - though, it’s a very low risk there since this code is quite mature and it’s not touched often. On the other hand, it should give time for users (several Beam releases) to update their code and use Avro from extension artifact instead of core.
Though, if we accept that this breaking change at compile time is allowable, then this process of transition should be much faster and can be performed within only one Beam release. Our main concern here is runtime breaking changes that we can miss but must be avoided by all means. — Alexey > On 9 Nov 2022, at 18:47, Austin Bennett <aus...@apache.org> wrote: > > 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 > <mailto: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 >>> <mailto: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 >>
