Thanks a lot for the feedback so far! I can only second Alexey. It was painful to come to realize that the only feasible option seems to be copying a lot of code during the transition phase. For that reason, it will be critical to be disciplined about the removal of the to-be deprecated code in core and, ahead of time, agree on when to remove it again. Any thought on how long the transition phase should be?
I am concerned of what could go wrong for users in the in-between/transition state while more slowly transitioning avro to extension. @Austin Do you have any specific concern in mind here? To minimize this risk, we propose that all APIs should be kept as is to make the migration as easy as possible and kick off with the Avro version used in core. The only thing that changes will be package names. / Moritz On 10.11.22, 22:46, "Kenneth Knowles" <k...@apache.org> wrote: 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 might have the most context on any technical issue we will 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<mailto: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<mailto: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<mailto: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<https://urldefense.com/v3/__https:/lists.apache.org/thread/mz8hvz8dwhd0tzmv2lyobhlz7gtg4gq7__;!!CiXD_PY!ThEMK5roxk1uO6Fpjmb3STnoNeOVFmjhytcQpHAT6WFXjpRioz7nJPSvMRRHwUXJovjHbRvmvA$> [2] https://docs.google.com/document/d/1tKIyTk_-HhkmVuJsxvWP5eTELESpCBe_Vmb1nJ3Ia34/edit?usp=sharing<https://urldefense.com/v3/__https:/docs.google.com/document/d/1tKIyTk_-HhkmVuJsxvWP5eTELESpCBe_Vmb1nJ3Ia34/edit?usp=sharing__;!!CiXD_PY!ThEMK5roxk1uO6Fpjmb3STnoNeOVFmjhytcQpHAT6WFXjpRioz7nJPSvMRRHwUXJoviZ8R6YKA$> — Alexey As a recipient of an email from Talend, your contact personal data will be on our systems. Please see our privacy notice. <https://www.talend.com/privacy/>
