Thank you for writing this document. It really helps to understand the options. I agree that option 2 (make a new extension and deprecate from core) seems best. I think +Reuven Lax <re...@google.com> might have the most context on any technical issue we will encounter around schema codegen.
Kenn On Thu, Nov 10, 2022 at 7:24 AM Alexey Romanenko <aromanenko....@gmail.com> wrote: > 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> > 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 >> >> >> >
