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 |
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 <[hidden email]> 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 |
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 <[hidden email]> 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 <[hidden email]> 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 |
I don't think we can script this (yet) in the release process, because the
actual releasing (as opposed to the candidate creation process) is not automated. I just updated the https://cwiki.apache.org/confluence/display/FLINK/Releasing guide and included the japicmp Flink reference version change into the TODO list. I'm not sure if we need to make things more complicated than necessary without having an actual problem we want to solve. Afaik, there was no incidence yet where a user was running into troubles with a breaking change between a minor version change. So tl;dr: just updating the reference version to 1.2.0 in "master" and "release-1.2" is in my opinion sufficient. On Thu, Mar 16, 2017 at 9:06 PM, Greg Hogan <[hidden email]> wrote: > 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 <[hidden email]> > 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 <[hidden email]> 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 > > |
Free forum by Nabble | Edit this page |