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]
