We have a Client Features Matrix page on the GitHub wiki [0]. This seems like a helpful and relevant resource for this thread.
It is only in a Google Sheet right now, though. Maybe the owners of the Google doc would consider contributing it to the website? The website references this matrix on this page [1], but the link is broken. Additionally, we could adopt the practice of sending a note to the mailing list when we add new features or find tricky bugs for any of our clients. Thanks, Michael [0] https://github.com/apache/pulsar/wiki/PIP-108:-Pulsar-Feature-Matrix-(Client-and-Function) [1] https://pulsar.apache.org/docs/en/client-libraries/ On Thu, Jan 13, 2022 at 8:53 PM r...@apache.org <ranxiaolong...@gmail.com> wrote: > > Good ideas, we need such a mechanism to complement the current process to > ensure that other language SDKs know what's going on with the Java SDK, > which would be a good start for other language SDKs. We can clearly see > where the gap between the current SDK and the Java SDK is, which new > functions we need to support, and which bugs we need to modify. > > We can perform this process manually first, although it is troublesome, but > in this action, we can find out what we need to do to automate such a > process, I believe this will be a good start. > > -- > Thanks > Xiaolong Ran > > PengHui Li <peng...@apache.org> 于2022年1月13日周四 11:16写道： > > > I'm not sure if the bots can detect if the change is a Java client change, > > maybe based on the changes introduced in which directory. > > > > The main headache here is missing it. If there are some mechanisms that can > > remind us. > > It will be great. Looks like > > > > "hey, new changes introduced in Java client, you might need to create an > > issue to other clients repos" > > > > Use a label to allow the bots to sync to other repos LGTM here, we can run > > it manually first. > > So that we can know more clearly if we need automatic synchronization. > > > > Thanks, > > Penghui > > > > On Wed, Jan 12, 2022 at 9:06 PM Zike Yang <zky...@streamnative.io.invalid> > > wrote: > > > > > +1 > > > > > > > I wonder if we can create issue in client repo automatically with bots > > > for PRs labelled"component/client" in pulsar repo. > > > > This would save the extra effort for the reviewer. > > > > > > But there are many PRs with "component/client" label that are specific > > > to java client changes. I think these should not be added to other > > > clients' repos. > > > > > > > > > > > > On Wed, Jan 12, 2022 at 4:18 PM Haiting Jiang <jianghait...@apache.org> > > > wrote: > > > > > > > > +1. Great idea. > > > > > > > > I wonder if we can create issue in client repo automatically with bots > > > for PRs labelled"component/client" in pulsar repo. > > > > This would save the extra effort for the reviewer. > > > > > > > > Thanks, > > > > Haiting Jiang > > > > > > > > On 2022/01/12 03:45:18 "r...@apache.org" wrote: > > > > > Hello everyone: > > > > > > > > > > At present, all our PIP and related function changes are mainly in > > the > > > Java > > > > > language, and all new functions will be merged into the Java SDK > > > first, but > > > > > for SDKs in other languages, this is completely a black box, they > > don't > > > > > know what changes or optimizations have been made on the Java SDK > > side. > > > > > > > > > > The most typical problem is that when users of other languages > > > encounter > > > > > various problems during use, when the maintainers of other languages > > > want > > > > > to fix these problems, we do not know that the Java SDK side has made > > > these > > > > > changes. Therefore, every current solution is to constantly check > > > where the > > > > > gap of the current Java SDK is, which brings great challenges to the > > > > > maintainers themselves. > > > > > > > > > > So here is an idea, when the committters/PMC responsible for > > reviewing > > > the > > > > > Java SDK can do more to help evaluate whether these PIPs or new > > changes > > > > > need to support this function in other languages, and then the > > > > > corresponding issue is created in the corresponding SDK, so that it > > is > > > > > convenient for the maintainers of other language SDKs to further > > > evaluate > > > > > the priority of this function, and it can also attract more > > > contributors > > > > > who are good at certain languages to claim the corresponding issue > > and > > > > > contribute the corresponding function. > > > > > > > > > > -- > > > > > Thanks > > > > > Xiaolong Ran > > > > > > > > > > > > > > > > > -- > > > Zike Yang > > > > >
