Thanks for the info David and Michael (and welcome for your first post)! It's been a month and we've got a bit of guidance and info, let's just call the vote. I have to admit that I specifically went to a gradle talk at ApacheCon this year to learn a bit myself :D I'll send a message soon!
Ryan On Fri, Sep 9, 2022 at 11:10 PM David M. Carr <[email protected]> wrote: > > I hadn't heard of avro-util before. That's interesting. I'm not surprised > that LinkedIn was the source of something like that, though. They're one > of the larger users of the plugin, from what I hear through the grapevine. > > As for how often Gradle breaks compatibility... it depends on what you > consider a "break", and how willing you are to do workarounds. For > example, when they roll out a new feature that will improve build > performance, it often requires use of a new API which wasn't present in > previous versions. You can either not support it (in which case the plugin > will usually work fine, as they pay a fair amount of attention to backwards > compatibility), though after some number of versions the old way may be > deprecated and eventually removed. If you do support it, you might > consider using reflection to use the old/new API depending on the version, > especially for minor changes. > > I'm currently supporting Gradle 5.1 (released Jan 02, 2019) to 7.3 > (released Nov 09, 2021). I expect the most recent versions are also > compatible, but haven't updated the testing matrix recently. The last time > I dropped support for older Gradle versions was in order to support Task > Configuration Avoidance; see > https://docs.gradle.org/current/userguide/task_configuration_avoidance.html. > > On Fri, Sep 9, 2022 at 1:34 PM Michael Kohout <[email protected]> wrote: > > > Hi Ryan and David- > > > > Long time lurker, first time poster. > > > > I've got a lot of experience with Avro and Gradle, where I forked/extended > > David's plugin(and the added capabilities to the SpecificCompiler) to > > support some use cases that aren't part of his plugin or apache-tools. > > > > I'm not with that company anymore and am in a position where I could > > contribute some effort... > > > > Mike > > > > > > On Fri, Sep 9, 2022 at 11:23 AM Ryan Skraba <[email protected]> wrote: > > > > > An offer of time also also well-appreciated! I'd love to hear from > > > any contributors that have gradle experience as well: would it be > > > appropriate and useful to have an official gradle plugin under the > > > Apache Avro repo? > > > > > > To answer your question, I can only really speak for what we do with > > > Maven: it's fairly straightforward: the plugin version matches the > > > version of Avro and supports the same Java versions. We never > > > generate code for previous versions of Avro. > > > > > > I.e., The Avro maven plugin 1.11.1 generates code with the Avro > > > SpecificCompiler 1.11.1, which is usually used with the Avro 1.11.1 > > > libraries (with Java 8 and up). > > > > > > On a related subject, I _used_ to think it was mandatory to match the > > > generated code with the avro libraries in use, and we've broken > > > compatibility with generated code in the past. There's an amazing > > > avro-util library to help generated code work across all versions[1]. > > > It's a pretty cool way to reuse generated code across Avro versions, > > > but we're also trying to keep in mind that people sometimes have mixed > > > environments (and AVOID break generated code compatibility). > > > > > > I'm not familiar with how much gradle breaks between versions... Maven > > > has been remarkably stable, and the Avro maven plugin still works with > > > Maven 3.2.x. > > > > > > [1]: https://github.com/linkedin/avro-util/ > > > > > > > > > On Thu, Sep 8, 2022 at 7:05 PM David M. Carr <[email protected]> wrote: > > > > > > > > If we were pursuing a donation of the plugin to the Avro project, I > > could > > > > definitely make some time available to guide (or even directly assist) > > > with > > > > the transition. > > > > > > > > The main area that requires consideration is the policy for version > > > > support/compatibility. What versions of Gradle/Avro/Java do you want > > to > > > > support for new plugin releases? Do you only publish a single variant, > > > or > > > > do you publish multiple variants to expand your version coverage? What > > > do > > > > you do when one of the dependencies makes a breaking change? > > > > > > > > Historically, my answer has been that I publish a single variant that > > > > supports the latest released version of each dependency, with > > best-effort > > > > compatibility with previous versions (and CI coverage to allow for > > > accurate > > > > documentation of what the supported ranges are). When a dependency > > > > releases a breaking change, I cut support for previous versions (and > > > > document the last plugin version that supported the previous version). > > > > > > > > I have plans for an approach that would allow for a single Gradle > > plugin > > > > release to support "all" Avro versions, and a prototype branch > > > > demonstrating the technique, but have been unable to put adequate time > > > > together to port the whole plugin over to that approach. At that > > point, > > > > the question would be simplified to what Avro versions and what Gradle > > > > versions are supported, separately, rather than the combination > > thereof. > > > > > > > > On Thu, Sep 8, 2022 at 12:32 PM Ryan Skraba <[email protected]> wrote: > > > > > > > > > Hello David! This is a very generous offer -- I think it's really > > > > > quite nice to consider donating it to the Apache Avro community, > > > > > especially since it looks like it's a well-appreciated feature and > > > > > you've put quite a bit of effort into it! > > > > > > > > > > I personally think this would be a welcome addition to the Avro > > > > > project. We've accepted code donations in the past, we usually > > > > > discuss it on the mailing list among devs and then call a vote (See > > > > > the Rust SDK[1]). > > > > > > > > > > I downloaded, compiled and tested the project in a matter of minutes, > > > > > which is really promising! We currently use Maven (of course) for > > all > > > > > of our Java code, but I don't see it being a blocker to introduce > > > > > Gradle to build a Gradle plugin. > > > > > > > > > > You mentioned not having as much time to dedicate to this, but you > > > > > probably have some useful insights! Are you looking for someone to > > > > > just take the existing repo as-is, and repackage/adapt it into the > > > > > existing Avro project, or would you have some time (even limited) to > > > > > help guide us into putting it in place? Is there anything we should > > > > > especially consider? > > > > > > > > > > All my best, Ryan > > > > > > > > > > [1]: > > https://lists.apache.org/thread/m3r4svytnn6do9tw0476nwttgtcp60qj > > > > > "Rust donation vote." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 7, 2022 at 3:16 PM David M. Carr <[email protected]> > > > wrote: > > > > > > > > > > > > In case someone on the list is interested: > > > > > > https://github.com/davidmc24/gradle-avro-plugin/discussions/208 > > > > > > > > > > > > Alternatively, if the Apache Avro project itself is interested in > > > having > > > > > an > > > > > > official Gradle plugin, the source is freely available and already > > > Apache > > > > > > licensed. > > > > > > > > > > > > -- > > > > > > David M. Carr > > > > > > [email protected] > > > > > > > > > > > > > > > > > -- > > > > David M. Carr > > > > [email protected] > > > > > > > > -- > David M. Carr > [email protected]
