@donal There is a violation filter in place for major version changes that would currently allow any change. That can be narrowed down to only allow deletion of already-deprecated signatures.
On Wed, May 13, 2020 at 5:18 PM Owen Nichols <onich...@pivotal.io> wrote: > If ApiChecker fails on your PR, and you merge anyway, it will fail on > develop, so there’s no question it should be a required PR check. > > We left some checks optional to avoid blocking merges on unrelated flaky > failures. ApiChecker should never be flaky. > > If/when Geode decides it’s time for a 2.0 release, which would allow > breaking backward compatibility, we should be able to provide a rule to > allow that in the ApiChecker. > > > On May 13, 2020, at 3:49 PM, Donal Evans <doev...@pivotal.io> wrote: > > > > Given that this job takes less than 10 minutes to run, pass or fail, I > > don't see it adding any additional friction to the PR process in terms of > > having to wait for things to finish. I am curious if there are any > > circumstances we could envisage where skipping or bypassing this check > > would be warranted though, and what the procedure would be in those > cases. > > For example, how would it handle the removal of a deprecated method from > an > > API? It's not something that happens often, but it will happen eventually > > (I would hope). > > > > On Wed, May 13, 2020 at 2:32 PM Robert Houghton <rhough...@pivotal.io> > > wrote: > > > >> We have enabled this job on the develop and support 1.13 branches, and > it > >> is going well. I would like this to be a blocking job for our pull > >> requests. > >> > >> Are there any issues around this test that we want to address, or > reasons > >> to *not* have it be a blocking job in the PR pipeline? > >> > >> To seed the conversation, there is an issue I am working on with @Mario > >> Ivanac <mario.iva...@est.tech> regarding exemptions to the Gradle task. > >> > >> I would like to have a [VOTE] by end of week on this. > >> > >
