Suggest a micro change for added interface fields

[laeubi]

If one adds a field to an interface this will not result in any problem for the consumer or the provider of the interface.

Because of this these changes can be made in a micro package version
increment.

[merks]

I just wanted to point out that this (will not result in a problem) isn't strictly true. Here if we add this default method to Foo, bad things will definitely happen in Bar:

That being said, Java has been doing this regularly and I suspect the API tools checking has not adapted to the concept of default methods. I wonder why a field in an interface was ever done this way in the first place? I should also mention I did not read this in detail:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html

[github-actions]

Test Results

   285 files  ±0     285 suites  ±0   48m 36s ⏱️ - 2m 52s
 3 586 tests ±0   3 510 ✅ ±0   76 💤 ±0  0 ❌ ±0 
10 950 runs  ±0  10 719 ✅ ±0  231 💤 ±0  0 ❌ ±0 

Results for commit 6985cde. ± Comparison against base commit b8f34f6.

♻️ This comment has been updated with latest results.

[laeubi]

The important part about package versions is binary compatibility, and java says here:

Adding a default method, or changing a method from abstract to default, does not break compatibility with pre-existing binaries, but may cause an IncompatibleClassChangeError if a pre-existing binary attempts to invoke the method.

So even if it is binary compatible, I think its not sufficient for a micro change and therefore removed this now and only assume adding fields is safe.

I also want to note that currently everything is only made as a suggestion, so one is still allowed to do a minor or major increment if it seems more sufficient.