Robert, I was going to file a ticket but posted to the mailing list and was hoping for your input.
That may be the wrong configuration option but what I was thinking is that: - 1.3.0 should have a compatible API relative to 1.2.0 (no modifications, only additions) - 1.2.1+ should have the same API as 1.2.0 (no modifications or additions) unless explicitly overridden Do you think these configuration changes can be scripted as part of the release process? Greg > On Mar 16, 2017, at 12:29 PM, Robert Metzger <rmetz...@apache.org> wrote: > > Hi Greg, > > I was not able to update the version to 1.2.0 when updating to > 1.3-SNAPSHOT, because 1.2.0 was not released at that point in time :) > But I agree that we should update that version once the release is out. I > forgot to do it. > > I'm not sure if I completely understand "breakBuildOnModifications". Does > it fail the build even if somebody did a change that is non API breaking on > a @Public class? > > On Thu, Mar 16, 2017 at 3:37 PM, Greg Hogan <c...@greghogan.com> wrote: > >> Hi, >> >> I see in the parent pom.xml that 1.3-SNAPSHOT is checking for API >> stability against 1.1.4. Also, that this version was only bumped with >> FLINK-5617 late in the 1.2 development cycle. >> >> Should we bump this version as part of the release process, i.e. on the >> 1.2.0 release updating 1.3-SNAPSHOT to verify against 1.2.0? And should we >> be setting ‘breakBuildOnModifications’ [0] to true for patch releases >> (overridden when necessary)? >> >> [0] https://siom79.github.io/japicmp/MavenPlugin.html >> >> Greg
