Hi Matthias, I'm not an expert in japicmp. Is it possible to only disable this for deprecated APIs? Maybe add an exclusion for @Deprecated? I think that would reduce the risk of unintended breaking changes to deprecated APIs that are not yet ready for removal.
Best, Xintong On Thu, Aug 29, 2024 at 5:52 PM Gabor Somogyi <gabor.g.somo...@gmail.com> wrote: > Hi Matthias, > > I would turn japicmp for 2.0 off because adding a long list of exceptions > doesn't give any value. > 1.x and 2.x is not going to be compatible in any way and when 2.x released, > then that will be the new > japicmp baseline (after a heavy migration). > > What I see as a potential risk it that we break something which was not > intended, but fixing those > hopefully small amount of cases is less effort than maintaining an endless > list. > > BR, > G > > > On Thu, Aug 29, 2024 at 11:40 AM Matthias Pohl <map...@apache.org> wrote: > > > Hi everyone, > > for the 2.0 work, we are expecting to run into public API changes quite a > > bit. This would get picked up by the japicmp plugin. The usual way is to > > add exclusions to the plugin configuration [1] generating a (presumably > > long) list of API changes. > > > > I'm wondering whether we, instead, would want to disable the plugin [2] > for > > 2.0 entirely to lower effort on the contributors side. > > > > Best, > > Matthias > > > > [1] https://github.com/apache/flink/blob/master/pom.xml#L2367 > > [2] https://github.com/apache/flink/blob/master/pom.xml#L170 > > >
