Github user erikdw commented on the issue:
https://github.com/apache/storm/pull/2117
@srdo : I might be in the minority (though it's hard to tell, since as you
noted the email thread didn't get much traction), but I don't think there's
much advantage in changing existing ***external*** APIs just for adherence with
this specific coding style standard. I should note that we're not actually
using `storm-kafka-client` in our users' topologies yet because we haven't been
able to upgrade to Storm 1.0+ yet (partially because of backwards-incompatible
changes in code and behavior).
In my view, breaking of backwards compatibility should be done only when
actually necessary; e.g., changing package from `backtype` to `org.apache` was
a good reason, since we needed to make the project properly namespaced.
Whereas coding style adherence is not a very convincing reason.
Maybe someone with a view on the number & scale of breaking changes in
Storm 2.0 as compared to 1.0 could speak up? I'm fairly ignorant about the
"gestalt" of what is happening in Storm 2.0 and so don't know the answer to
that question. i.e., if everyone is going to have to make a bunch of changes
*anyways* then it's probably "no big deal" to slap in this method name casing
change. But if 2.0 isn't highly divergent as compared to 1.0 for topology
authors, then I'd argue this isn't worth it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
