> we can allow adding new "public" methods as you mentioned, but only if
this doesn't change the semantics of an interface.
However, I think we should not allow introducing a new method to the
interface that is possibly used by the user to the patch release.
For instance, If a user is using a new
Hi Yunze,
Thanks for raising the discussion.
IMO, The major issue is we don't have a clear API definition for the
pulsar-broker module like
pulsar-client-api and pulsar-client-admin-api modules. We have a
clear Interface Taxonomy[0] for
pulsar-client-api and pulsar-client-admin-api modules. I don
Hi Enrico,
> Also adding it to all the existing classes is a big task.
Yes. I don't support adding it to existing classes as well. But we
need to apply the annotation for new code.
> because basically we wouldn't be able to commit change if we prevent
> adding/removing methods that are marked
Commenting on bringing up the example of PR
https://github.com/apache/pulsar/pull/20733 .
It isn't a good example of breaking compatibility at all.
The WebSocketPingPongServlet and PingPongHandler never made any sense.
The issue eclipse/jetty.project#4880 [1] explains that Websocket Pong
is provid
Yunze,
I agree overall with the proposal,
I added some comments inline below
Enrico
Il giorno ven 14 lug 2023 alle ore 13:25 Yunze Xu ha scritto:
>
> Good suggestion. We can try that.
>
> Thanks,
> Yunze
>
> On Fri, Jul 14, 2023 at 7:03 PM Lari Hotari wrote:
> >
> > Makes sense. We should use t
Good suggestion. We can try that.
Thanks,
Yunze
On Fri, Jul 14, 2023 at 7:03 PM Lari Hotari wrote:
>
> Makes sense. We should use tooling in CI to enforce binary
> compatibility of the modules that shouldn't break.
> There's japicmp [1] that can be used to do this. japicmp comes with a
> maven p
In addition to the rule of the patch releases, it's acceptable to have
new public methods for bug fixes, though we should pay enough effort
to avoid it. If so, we should not remove or change any public method.
I just checked a few recent PRs in branch-3.0 and added some examples here.
https://git
Makes sense. We should use tooling in CI to enforce binary
compatibility of the modules that shouldn't break.
There's japicmp [1] that can be used to do this. japicmp comes with a
maven plugin [2] that needs to be configured with the rules to be
used.
-Lari
1 - https://siom79.github.io/japicmp/
2
Hi all,
As the Pulsar community is growing, the core project could be depended
on by many ecosystem projects, including protocol handlers and
connectors. However, there is no clear API compatibility guarantee at
the moment.
For now, PIP is required when public APIs change [1]. However, I think
th
