Great proposal, thanks Matteo. I think I agree with splitting out the client into two repos. One issue is that new C++ features will lag in the python client because the C++ client will first need to be released. Quick releases will likely help there.
> Instead of just fetching the main repo code, the website build job should be > also fetching the new repos to run the tooling. The python documentation is generated by downloading the source tarball for a release [0] and then running pandoc in a docker container. The only change for the python docs will be to update where the source tarball is downloaded from and to ensure the release process is documented. I've wanted to do something similar with the C++ docs, but I haven't had a chance. > The client <--> broker compatibility is in general always guaranteed. I think we should make this more visible in our Pulsar documentation. It's a fantastic feature, and I get the sense that it is not well known. Thanks, Michael [0] https://github.com/apache/pulsar-site/tree/main/site2/tools/api/python On Tue, Sep 20, 2022 at 11:46 AM Matteo Merli <matteo.me...@gmail.com> wrote: > > -- > Matteo Merli > <matteo.me...@gmail.com> > > On Mon, Sep 19, 2022 at 7:30 PM Baodi Shi <baodi....@icloud.com.invalid> > wrote: > > > The suggestion is to start the new releases for both C++ and Python from > > > 3.0.0. > > > > In the future, Can we need to maintain a compatibility list? For the user, > > how should he choose the appropriate client version to match the broker? > > That would be very similar to other languages as well. The client <--> > broker compatibility is in general always guaranteed. > > The only thing to be aware of is with respect to particular features. > eg: if I want to use feature X I need to make sure that the broker is > at a version that supports it, as well as the client. > > Today, based on the lag with which the features are introduced in > clients other than Java, using a C++ client for 2.8.4 does not > guarantee that a feature supported by broker is available in the same > version of the client. > > > > The different location of the new C++ code will make the cherry-picking > > > process > > > slightly more painful in the short term, though it will even out in long > > > term. > > > > The current existing issue, is need to move to the new repository? > > Good question, we could use a scripts that creates issues in the new > repo linking back to the old repo issue. (everything that's currently > tagged with 'cpp' label).
