Bumping API stability check version

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bumping API stability check version

Greg Hogan
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
Reply | Threaded
Open this post in threaded view
|

Re: Bumping API stability check version

Robert Metzger
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
Reply | Threaded
Open this post in threaded view
|

Re: Bumping API stability check version

Greg Hogan
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

Reply | Threaded
Open this post in threaded view
|

Re: Bumping API stability check version

Robert Metzger
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
>
>