Ok, thanks! I've submitted https://github.com/apache/geode/pull/4748 to
revert the change. I'll be offline for a while so feel free to merge it if
it passes.
Thanks,
Kirk
On Thu, Feb 27, 2020 at 5:19 PM Owen Nichols wrote:
> While changing a void method to have a return type does not break sour
Another affect is code deployment onto/into the server, which
could/would reference a change (binary) API. Users generally don't
recompile the code they redeploy. The NoSuchMethod is now harder to
track down.
--Udo
On 2/28/20 8:59 AM, Anthony Baker wrote:
If I run the japi-compliance-checke
If I run the japi-compliance-checker [1] against the 1.12 release branch and
develop this change pops up as a binary incompatibility. As Owen noted, this
would require recompilation to avoid NoSuchMethod errors.
One effect this could have is that a library built on top of Geode (e.g.
Spring) w
While changing a void method to have a return type does not break source
compatibility, it appears likely to break binary compatibility[1].
So, if you are compiling your client from source, it will compile successfully
against either Geode 1.12 or Geode 1.13. But if your client was already
com
Remember, if there are any concerns about recent backwards-compatible
changes to Geode user APIs, they should be brought on the dev list.
Also, backward-compatible changes are by definition safe and ok for a user
API because it won't break the user's code.
Here's an example of a user API that I r
