Re: [VOTE] Pulsar Release 2.10.2 Candidate 2

[houxiaoyu]

Hi Haiting,

There is a significant performance regression about publish
throughput, more context is here:
https://github.com/apache/pulsar/issues/17931

The fixed PR is here:
https://github.com/apache/pulsar/pull/17948

This should be a release blocker I think.

Thanks,
Xiaoyu Hou

Haiting Jiang  于2022年10月6日周四 10:46写道：

> This is the second release candidate for Apache Pulsar, version 2.10.2.
>
> This release contains 249 commits by 57 contributors.
> https://github.com/apache/pulsar/compare/v2.10.1...v2.10.2-candidate-2
>
> CI for this release candidate
> https://github.com/Jason918/pulsar/pull/10
>
> *** Please download, test and vote on this release. This vote will stay
> open
> for at least 72 hours ***
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.2-candidate-2/
>
> SHA-512 checksums:
>
> 26dc11e1514aa286d934e2f9698f4a04def6424307dcc452324bf935e88ba97c2d75b480a88a98640010c0117293d128e389c3e4fa98ab51cfc19e9312f5d00a
>  ./apache-pulsar-2.10.2-bin.tar.gz
>
> 0eee2f47680966736acbdbdf309b0c7ccd4d10f737f49b6b8d9f5599a51d46568c1a0a18c75be6a44f78da60fe4287889d2e158fe530b20cee8b64411abe65f0
>  ./apache-pulsar-2.10.2-src.tar.gz
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1186/
>
> The tag to be voted upon:
> v2.10.2-candidate-2 (850c9448a5ac32e2f94988b8bf80955c93ef9d6c)
> https://github.com/apache/pulsar/releases/tag/v2.10.2-candidate-2
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
>
> Docker images:
>
> https://hub.docker.com/layers/jason918/pulsar/2.10.2/images/sha256-1ef93f17102e8193fc625fd5572f431d45935f7e2f11add3725a301c4321cef4
>
> https://hub.docker.com/layers/jason918/pulsar-all/2.10.2/images/sha256-6e6b49687b7debdf26feb71fedaa622de425885de5e2e7498dc476867cab85bc
>
> Please download the source package, and follow the
> release-candidate-validation doc to build
> and run the Pulsar standalone service.
>
> https://github.com/apache/pulsar/blob/master/wiki/release/release-candidate-validation.md
>
> Thanks,
> Haiting
>

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Dave Fisher]

Thanks Lari.

I have a pain point that is about documentation and developer awareness where 
we can help improve quality and suggest improvements.

1) Work on clear documentation about each thread pool and how it is used by the 
classes in the message path.
2) Add thread pool impacts to the PR template to help prevent performance 
regressions and focus on improvements.
3) identify performance bottlenecks that already exist where a thread pool 
change might help.

Regards,
Dave

Sent from my iPhone

> On Oct 7, 2022, at 10:17 PM, Lari Hotari  wrote:
> 
> Thanks, Dave for sharing your views. I entirely agree.
> 
> -Lari
> 
>> On 2022/10/08 01:41:47 Dave Fisher wrote:
>> To me the point of this discussion is for the community to discuss both 
>> improvement ideas along with current pain points in the broker. Whether or 
>> not the ideas and proposed solutions are breaking or incremental is yet to 
>> be determined. Let’s not get hung up on versions or nomenclature.
>> 
>> All the best,
>> Dave
>> 
>> Sent from my iPhone
>> 
 On Oct 7, 2022, at 5:54 PM, Matteo Merli  wrote:
>>> 
>>> I actually disagree with the term "Pulsar Next Gen", because I haven't
>>> seen any proposal for which that would make sense to me to be called
>>> so.
>>> 
>>> Rajan: That's the whole point of breaking it down. If you accumulate
>>> many "big" changes it introduces a lot of risk for instabilities and
>>> incompatibilities. Breaking it down in multiple steps helps to see the
>>> incremental changes and introduced them in a phased manner.
>>> 
>>> 
>>> -- 
>>> Matteo Merli
>>> 
>>> 
 On Fri, Oct 7, 2022 at 3:37 PM Rajan Dhabalia  wrote:
 
 Hi,
 
 Can we get the list of changes at one place which we are planning to get as
 part of 3.0. One thing I would like to see as a part of a major release, it
 CAN NOT impact existing usecases and users in any way which can force them
 to upgrade the client library. Applications using < 3.0 version should
 continue getting all the client and server side enhancements and bug fixes.
 Failing to provide bug-fixes and features to client < 3.0 means we are
 forcing them to upgrade client version by putting efforts to handle all
 incompatibility. and that's something we should definitely prevent because
 Apache Pulsar is used by many large scale business usecases and we should
 accommodate and motivate them to continue using Apache Pulsar.
 I understand as a Pulsar community we should always try to progress and
 build better but not at the cost of losing or reducing the Apache Pulsar
 community.
 
 Thanks,
 Rajan
 
 
> On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:
> 
> Thank you, Matteo. I agree that features should be delivered continuously
> when that is possible. In this case, that might not apply.
> 
> I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
> PIP-175 since an LTS release is when the major version is bumped. I'm fine
> in calling this "Pulsar Next Gen" or something that calls out that this is
> planning for making a major leap in Pulsar.
> 
> There are several unresolved issues with PIP-45 and the Pulsar Load
> balancer. The previously referred email threads contain a lot of context 
> to
> this. Resolving the issues efficiently will most likely result in breaking
> changes, which will be the reason why it deserves a major version upgrade.
> 
> We have discussed it before that it's crucial to have a path to migrate
> users when there are breaking changes. This should be covered in any of 
> the
> solutions that are introduced. Optimally, users of Pulsar would be able to
> upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
> not be directly supported.
> 
> I am welcoming everyone to join this planning for the Apache Pulsar Next
> Gen architecture. Please check the first email in this thread for details
> of context, and start participating and contributing today. The best way 
> to
> contribute is to participate in the email threads, since they contain
> details with better context.
> 
> -Lari
> 
> On 2022/10/07 18:03:00 Matteo Merli wrote:
>> Given the past experiences and the discussions that already happened
>> around "PIP-175: Extend time based release process", the idea is to
>> detach the 3.0 from "big-features" items or "incompatible changes".
>> 
>> The changes are going to get included as they are ready, within
>> feature releases, and in a fully compatible way. We don't need to
>> group them together and create unnecessary risk for the release
>> schedule and the users.
>> 
>> 
>> --
>> Matteo Merli
>> 
>> 
>> On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
>>> 
>>> Hi all,
>>> 
>>> Greeting from ApacheCon North America 2022 

Re: [VOTE] Pulsar Client Go Release 0.9.0 Candidate 2

[Qiang Huang]

+1 (non-binding)
- Build from the source code
- Run producer and consumer

guo jiwei  于2022年10月8日周六 11:27写道：

> +1 (binding)
>
> - Build from the source code
> - Run producer and consumer
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Sat, Oct 8, 2022 at 11:17 AM Zike Yang  wrote:
>
> > +1 (non-binding)
> > - Build from the source code
> > - Run producer and consumer
> > - Run pulsar-perf produce and consume
> >
> > Thanks,
> > Zike Yang
> >
> > On Sat, Oct 8, 2022 at 10:53 AM Hang Chen  wrote:
> > >
> > > +1(binding)
> > > - Check sha 512 for the source code
> > > - Build from the source code
> > > - Run produce and consume
> > >
> > > Thanks,
> > > Hang
> > >
> > > PengHui Li  于2022年9月29日周四 22:06写道：
> > > >
> > > > +1 (binding)
> > > >
> > > > - build from the source code
> > > > - test the produce and consume
> > > >
> > > > Penghui
> > > >
> > > > On Thu, Sep 29, 2022 at 2:43 PM Guangning E 
> > wrote:
> > > >
> > > > > +1(non-binding)
> > > > > - Check sha 512 value for source code
> > > > > - Check go build producer example
> > > > >
> > > > > Thanks,
> > > > > Guangning
> > > > >
> > > > > r...@apache.org  于2022年9月29日周四 14:35写道：
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > Please review and vote on the release candidate #2 for the
> version
> > 0.9.0,
> > > > > > as follows:
> > > > > > [ ] +1, Approve the release
> > > > > > [ ] -1, Do not approve the release (please provide specific
> > comments)
> > > > > >
> > > > > > This is the second release candidate for Apache Pulsar Go client,
> > > > > > version 0.9.0.
> > > > > >
> > > > > > It fixes the following issues:
> > > > > > https://github.com/apache/pulsar-client-go/milestone/10?closed=1
> > > > > >
> > > > > > Pulsar Client Go's KEYS file contains PGP keys we used to sign
> this
> > > > > > release:
> > > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > > > > >
> > > > > > Please download these packages and review this release candidate:
> > > > > > - Review release notes
> > > > > https://github.com/apache/pulsar-client-go/pull/804
> > > > > > - Download the source package (verify shasum, and asc) and follow
> > the
> > > > > > README.md to build and run the pulsar-client-go.
> > > > > >
> > > > > > The vote will be open for at least 72 hours. It is adopted by
> > majority
> > > > > > approval, with at least 3 PMC affirmative votes.
> > > > > >
> > > > > > Source file:
> > > > > >
> > > > > >
> > > > >
> >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.9.0-candidate-2/
> > > > > >
> > > > > > The tag to be voted upon:
> > > > > > v0.9.0
> > > > > >
> > > > >
> >
> https://github.com/apache/pulsar-client-go/releases/tag/v0.9.0-candidate-2
> > > > > >
> > > > > > SHA-512 checksums:
> > > > > >
> > > > > >
> > > > >
> >
> 9731d6a0615288e77feb4b73fedbbdf6d275ebefeee3cee5fc4e849f38789863f0532c7e8b93eb1e601bd98f9bb21d50a714fcf87fac9987a745a052bbe23ca3
> > > > > >  apache-pulsar-client-go-0.9.0-candidate-2-src.tar.gz
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Xiaolong Ran
> > > > > >
> > > > >
> >
>


-- 
BR,
Qiang Huang

Re: Pulsar Summit Asia 2022 CFP is Open Now!

[Sherlock Xu]

Dear community members,

The CFP will be closed soon! If you have any great ideas, do not forget to 
submit a proposal.

Thank you.
Sherlock Xu

> On Sep 20, 2022, at 11:36, Sherlock Xu  wrote:
> 
> Hi Apache Pulsar community members,
> 
> Pulsar Summit Asia 2022  will be 
> hosted virtually on November 19th and 20th, 2022. It is expected to cover the 
> pivotal topics and technologies at the core of Apache Pulsar. The CFP is open 
> now 
> !
>  We are excited to invite you to share your Pulsar experience. We are looking 
> for Pulsar stories that are innovative, informative, or thought-provoking. 
> Here are some suggestions:
> 
> Use cases, operations, tools, techniques, or the Pulsar ecosystem
> A deep dive into technologies
> Best practices and lessons learned
> A Pulsar success story or case study
> Anything else related to Pulsar that inspires the audience
> 
> To speak at the summit, submit an abstract 
>  about your session. All 
> levels of talks (beginner, intermediate, and advanced) are welcome. Remember 
> to keep your proposal short, relevant, and engaging.
> 
> Important dates to remember:
> 
> CFP opens: August 22nd, 2022
> CFP closes: October 9th, 2022
> CFP notifications: October 19th, 2022
> Schedule announcement: November 4th, 2022
> Event dates: November 19th, 2022 - November 20th, 2022
> 
> If you have any questions, contact us at organiz...@pulsar-summit.org 
> .
> 
> We are looking forward to your participation!
> 
> Best,
> Sherlock Xu

Re: [VOTE] Pulsar Client Go Release 0.9.0 Candidate 2

[guo jiwei]

+1 (binding)

- Build from the source code
- Run producer and consumer


Regards
Jiwei Guo (Tboy)


On Sat, Oct 8, 2022 at 11:17 AM Zike Yang  wrote:

> +1 (non-binding)
> - Build from the source code
> - Run producer and consumer
> - Run pulsar-perf produce and consume
>
> Thanks,
> Zike Yang
>
> On Sat, Oct 8, 2022 at 10:53 AM Hang Chen  wrote:
> >
> > +1(binding)
> > - Check sha 512 for the source code
> > - Build from the source code
> > - Run produce and consume
> >
> > Thanks,
> > Hang
> >
> > PengHui Li  于2022年9月29日周四 22:06写道：
> > >
> > > +1 (binding)
> > >
> > > - build from the source code
> > > - test the produce and consume
> > >
> > > Penghui
> > >
> > > On Thu, Sep 29, 2022 at 2:43 PM Guangning E 
> wrote:
> > >
> > > > +1(non-binding)
> > > > - Check sha 512 value for source code
> > > > - Check go build producer example
> > > >
> > > > Thanks,
> > > > Guangning
> > > >
> > > > r...@apache.org  于2022年9月29日周四 14:35写道：
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > Please review and vote on the release candidate #2 for the version
> 0.9.0,
> > > > > as follows:
> > > > > [ ] +1, Approve the release
> > > > > [ ] -1, Do not approve the release (please provide specific
> comments)
> > > > >
> > > > > This is the second release candidate for Apache Pulsar Go client,
> > > > > version 0.9.0.
> > > > >
> > > > > It fixes the following issues:
> > > > > https://github.com/apache/pulsar-client-go/milestone/10?closed=1
> > > > >
> > > > > Pulsar Client Go's KEYS file contains PGP keys we used to sign this
> > > > > release:
> > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > > > >
> > > > > Please download these packages and review this release candidate:
> > > > > - Review release notes
> > > > https://github.com/apache/pulsar-client-go/pull/804
> > > > > - Download the source package (verify shasum, and asc) and follow
> the
> > > > > README.md to build and run the pulsar-client-go.
> > > > >
> > > > > The vote will be open for at least 72 hours. It is adopted by
> majority
> > > > > approval, with at least 3 PMC affirmative votes.
> > > > >
> > > > > Source file:
> > > > >
> > > > >
> > > >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.9.0-candidate-2/
> > > > >
> > > > > The tag to be voted upon:
> > > > > v0.9.0
> > > > >
> > > >
> https://github.com/apache/pulsar-client-go/releases/tag/v0.9.0-candidate-2
> > > > >
> > > > > SHA-512 checksums:
> > > > >
> > > > >
> > > >
> 9731d6a0615288e77feb4b73fedbbdf6d275ebefeee3cee5fc4e849f38789863f0532c7e8b93eb1e601bd98f9bb21d50a714fcf87fac9987a745a052bbe23ca3
> > > > >  apache-pulsar-client-go-0.9.0-candidate-2-src.tar.gz
> > > > >
> > > > > Best,
> > > > >
> > > > > Xiaolong Ran
> > > > >
> > > >
>

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Lari Hotari]

Thank you, Matteo. I'm just adding that it all makes sense that what you said.

I hope that my other email clarified the need to get loose of any restrictions 
for a while in the planning of Pulsar 3.0. Making the changes a reality is 
something where the practice of incremental changes that you have introduced to 
Pulsar development will continue to be essential. This might need more 
clarification, but I think that we will be able to resolve it when it becomes 
current.

-Lari

On 2022/10/07 22:53:59 Matteo Merli wrote:
> I actually disagree with the term "Pulsar Next Gen", because I haven't
> seen any proposal for which that would make sense to me to be called
> so.
> 
> Rajan: That's the whole point of breaking it down. If you accumulate
> many "big" changes it introduces a lot of risk for instabilities and
> incompatibilities. Breaking it down in multiple steps helps to see the
> incremental changes and introduced them in a phased manner.
> 
> 
> -- 
> Matteo Merli
> 
> 
> On Fri, Oct 7, 2022 at 3:37 PM Rajan Dhabalia  wrote:
> >
> > Hi,
> >
> > Can we get the list of changes at one place which we are planning to get as
> > part of 3.0. One thing I would like to see as a part of a major release, it
> > CAN NOT impact existing usecases and users in any way which can force them
> > to upgrade the client library. Applications using < 3.0 version should
> > continue getting all the client and server side enhancements and bug fixes.
> > Failing to provide bug-fixes and features to client < 3.0 means we are
> > forcing them to upgrade client version by putting efforts to handle all
> > incompatibility. and that's something we should definitely prevent because
> > Apache Pulsar is used by many large scale business usecases and we should
> > accommodate and motivate them to continue using Apache Pulsar.
> > I understand as a Pulsar community we should always try to progress and
> > build better but not at the cost of losing or reducing the Apache Pulsar
> > community.
> >
> > Thanks,
> > Rajan
> >
> >
> > On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:
> >
> > > Thank you, Matteo. I agree that features should be delivered continuously
> > > when that is possible. In this case, that might not apply.
> > >
> > > I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
> > > PIP-175 since an LTS release is when the major version is bumped. I'm fine
> > > in calling this "Pulsar Next Gen" or something that calls out that this is
> > > planning for making a major leap in Pulsar.
> > >
> > > There are several unresolved issues with PIP-45 and the Pulsar Load
> > > balancer. The previously referred email threads contain a lot of context 
> > > to
> > > this. Resolving the issues efficiently will most likely result in breaking
> > > changes, which will be the reason why it deserves a major version upgrade.
> > >
> > > We have discussed it before that it's crucial to have a path to migrate
> > > users when there are breaking changes. This should be covered in any of 
> > > the
> > > solutions that are introduced. Optimally, users of Pulsar would be able to
> > > upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
> > > not be directly supported.
> > >
> > > I am welcoming everyone to join this planning for the Apache Pulsar Next
> > > Gen architecture. Please check the first email in this thread for details
> > > of context, and start participating and contributing today. The best way 
> > > to
> > > contribute is to participate in the email threads, since they contain
> > > details with better context.
> > >
> > > -Lari
> > >
> > > On 2022/10/07 18:03:00 Matteo Merli wrote:
> > > > Given the past experiences and the discussions that already happened
> > > > around "PIP-175: Extend time based release process", the idea is to
> > > > detach the 3.0 from "big-features" items or "incompatible changes".
> > > >
> > > > The changes are going to get included as they are ready, within
> > > > feature releases, and in a fully compatible way. We don't need to
> > > > group them together and create unnecessary risk for the release
> > > > schedule and the users.
> > > >
> > > >
> > > > --
> > > > Matteo Merli
> > > > 
> > > >
> > > > On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Greeting from ApacheCon North America 2022 from New Orleans!
> > > > > We had a great conference with a dedicated Pulsar track. Thanks to all
> > > presenters and everyone who attended. The talks weren't recorded, but the
> > > slides will be later on posted on the conference website [1].
> > > > >
> > > > > At ApacheCon there were several presentations about "the Apache way"
> > > and what that means in practice. Based on that, we all know that no person
> > > is nominated as the CTO of Apache Pulsar who decides on Pulsar 3.0 and 
> > > when
> > > that happens. It's us, the community, that serve that role together. We
> > > come together as individuals 

Re: [VOTE] Pulsar Client Go Release 0.9.0 Candidate 2

[Zike Yang]

+1 (non-binding)
- Build from the source code
- Run producer and consumer
- Run pulsar-perf produce and consume

Thanks,
Zike Yang

On Sat, Oct 8, 2022 at 10:53 AM Hang Chen  wrote:
>
> +1(binding)
> - Check sha 512 for the source code
> - Build from the source code
> - Run produce and consume
>
> Thanks,
> Hang
>
> PengHui Li  于2022年9月29日周四 22:06写道：
> >
> > +1 (binding)
> >
> > - build from the source code
> > - test the produce and consume
> >
> > Penghui
> >
> > On Thu, Sep 29, 2022 at 2:43 PM Guangning E  wrote:
> >
> > > +1(non-binding)
> > > - Check sha 512 value for source code
> > > - Check go build producer example
> > >
> > > Thanks,
> > > Guangning
> > >
> > > r...@apache.org  于2022年9月29日周四 14:35写道：
> > >
> > > > Hi everyone,
> > > >
> > > > Please review and vote on the release candidate #2 for the version 
> > > > 0.9.0,
> > > > as follows:
> > > > [ ] +1, Approve the release
> > > > [ ] -1, Do not approve the release (please provide specific comments)
> > > >
> > > > This is the second release candidate for Apache Pulsar Go client,
> > > > version 0.9.0.
> > > >
> > > > It fixes the following issues:
> > > > https://github.com/apache/pulsar-client-go/milestone/10?closed=1
> > > >
> > > > Pulsar Client Go's KEYS file contains PGP keys we used to sign this
> > > > release:
> > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > > >
> > > > Please download these packages and review this release candidate:
> > > > - Review release notes
> > > https://github.com/apache/pulsar-client-go/pull/804
> > > > - Download the source package (verify shasum, and asc) and follow the
> > > > README.md to build and run the pulsar-client-go.
> > > >
> > > > The vote will be open for at least 72 hours. It is adopted by majority
> > > > approval, with at least 3 PMC affirmative votes.
> > > >
> > > > Source file:
> > > >
> > > >
> > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.9.0-candidate-2/
> > > >
> > > > The tag to be voted upon:
> > > > v0.9.0
> > > >
> > > https://github.com/apache/pulsar-client-go/releases/tag/v0.9.0-candidate-2
> > > >
> > > > SHA-512 checksums:
> > > >
> > > >
> > > 9731d6a0615288e77feb4b73fedbbdf6d275ebefeee3cee5fc4e849f38789863f0532c7e8b93eb1e601bd98f9bb21d50a714fcf87fac9987a745a052bbe23ca3
> > > >  apache-pulsar-client-go-0.9.0-candidate-2-src.tar.gz
> > > >
> > > > Best,
> > > >
> > > > Xiaolong Ran
> > > >
> > >

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Lari Hotari]

Thanks, Dave for sharing your views. I entirely agree.

-Lari

On 2022/10/08 01:41:47 Dave Fisher wrote:
> To me the point of this discussion is for the community to discuss both 
> improvement ideas along with current pain points in the broker. Whether or 
> not the ideas and proposed solutions are breaking or incremental is yet to be 
> determined. Let’s not get hung up on versions or nomenclature.
> 
> All the best,
> Dave
> 
> Sent from my iPhone
> 
> > On Oct 7, 2022, at 5:54 PM, Matteo Merli  wrote:
> > 
> > I actually disagree with the term "Pulsar Next Gen", because I haven't
> > seen any proposal for which that would make sense to me to be called
> > so.
> > 
> > Rajan: That's the whole point of breaking it down. If you accumulate
> > many "big" changes it introduces a lot of risk for instabilities and
> > incompatibilities. Breaking it down in multiple steps helps to see the
> > incremental changes and introduced them in a phased manner.
> > 
> > 
> > -- 
> > Matteo Merli
> > 
> > 
> >> On Fri, Oct 7, 2022 at 3:37 PM Rajan Dhabalia  wrote:
> >> 
> >> Hi,
> >> 
> >> Can we get the list of changes at one place which we are planning to get as
> >> part of 3.0. One thing I would like to see as a part of a major release, it
> >> CAN NOT impact existing usecases and users in any way which can force them
> >> to upgrade the client library. Applications using < 3.0 version should
> >> continue getting all the client and server side enhancements and bug fixes.
> >> Failing to provide bug-fixes and features to client < 3.0 means we are
> >> forcing them to upgrade client version by putting efforts to handle all
> >> incompatibility. and that's something we should definitely prevent because
> >> Apache Pulsar is used by many large scale business usecases and we should
> >> accommodate and motivate them to continue using Apache Pulsar.
> >> I understand as a Pulsar community we should always try to progress and
> >> build better but not at the cost of losing or reducing the Apache Pulsar
> >> community.
> >> 
> >> Thanks,
> >> Rajan
> >> 
> >> 
> >>> On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:
> >>> 
> >>> Thank you, Matteo. I agree that features should be delivered continuously
> >>> when that is possible. In this case, that might not apply.
> >>> 
> >>> I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
> >>> PIP-175 since an LTS release is when the major version is bumped. I'm fine
> >>> in calling this "Pulsar Next Gen" or something that calls out that this is
> >>> planning for making a major leap in Pulsar.
> >>> 
> >>> There are several unresolved issues with PIP-45 and the Pulsar Load
> >>> balancer. The previously referred email threads contain a lot of context 
> >>> to
> >>> this. Resolving the issues efficiently will most likely result in breaking
> >>> changes, which will be the reason why it deserves a major version upgrade.
> >>> 
> >>> We have discussed it before that it's crucial to have a path to migrate
> >>> users when there are breaking changes. This should be covered in any of 
> >>> the
> >>> solutions that are introduced. Optimally, users of Pulsar would be able to
> >>> upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
> >>> not be directly supported.
> >>> 
> >>> I am welcoming everyone to join this planning for the Apache Pulsar Next
> >>> Gen architecture. Please check the first email in this thread for details
> >>> of context, and start participating and contributing today. The best way 
> >>> to
> >>> contribute is to participate in the email threads, since they contain
> >>> details with better context.
> >>> 
> >>> -Lari
> >>> 
> >>> On 2022/10/07 18:03:00 Matteo Merli wrote:
>  Given the past experiences and the discussions that already happened
>  around "PIP-175: Extend time based release process", the idea is to
>  detach the 3.0 from "big-features" items or "incompatible changes".
>  
>  The changes are going to get included as they are ready, within
>  feature releases, and in a fully compatible way. We don't need to
>  group them together and create unnecessary risk for the release
>  schedule and the users.
>  
>  
>  --
>  Matteo Merli
>  
>  
>  On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
> > 
> > Hi all,
> > 
> > Greeting from ApacheCon North America 2022 from New Orleans!
> > We had a great conference with a dedicated Pulsar track. Thanks to all
> >>> presenters and everyone who attended. The talks weren't recorded, but the
> >>> slides will be later on posted on the conference website [1].
> > 
> > At ApacheCon there were several presentations about "the Apache way"
> >>> and what that means in practice. Based on that, we all know that no person
> >>> is nominated as the CTO of Apache Pulsar who decides on Pulsar 3.0 and 
> >>> when
> >>> that happens. It's us, the community, that serve that role together. We
> 

Re: [VOTE] Pulsar Client Go Release 0.9.0 Candidate 2

[Hang Chen]

+1(binding)
- Check sha 512 for the source code
- Build from the source code
- Run produce and consume

Thanks,
Hang

PengHui Li  于2022年9月29日周四 22:06写道：
>
> +1 (binding)
>
> - build from the source code
> - test the produce and consume
>
> Penghui
>
> On Thu, Sep 29, 2022 at 2:43 PM Guangning E  wrote:
>
> > +1(non-binding)
> > - Check sha 512 value for source code
> > - Check go build producer example
> >
> > Thanks,
> > Guangning
> >
> > r...@apache.org  于2022年9月29日周四 14:35写道：
> >
> > > Hi everyone,
> > >
> > > Please review and vote on the release candidate #2 for the version 0.9.0,
> > > as follows:
> > > [ ] +1, Approve the release
> > > [ ] -1, Do not approve the release (please provide specific comments)
> > >
> > > This is the second release candidate for Apache Pulsar Go client,
> > > version 0.9.0.
> > >
> > > It fixes the following issues:
> > > https://github.com/apache/pulsar-client-go/milestone/10?closed=1
> > >
> > > Pulsar Client Go's KEYS file contains PGP keys we used to sign this
> > > release:
> > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > >
> > > Please download these packages and review this release candidate:
> > > - Review release notes
> > https://github.com/apache/pulsar-client-go/pull/804
> > > - Download the source package (verify shasum, and asc) and follow the
> > > README.md to build and run the pulsar-client-go.
> > >
> > > The vote will be open for at least 72 hours. It is adopted by majority
> > > approval, with at least 3 PMC affirmative votes.
> > >
> > > Source file:
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.9.0-candidate-2/
> > >
> > > The tag to be voted upon:
> > > v0.9.0
> > >
> > https://github.com/apache/pulsar-client-go/releases/tag/v0.9.0-candidate-2
> > >
> > > SHA-512 checksums:
> > >
> > >
> > 9731d6a0615288e77feb4b73fedbbdf6d275ebefeee3cee5fc4e849f38789863f0532c7e8b93eb1e601bd98f9bb21d50a714fcf87fac9987a745a052bbe23ca3
> > >  apache-pulsar-client-go-0.9.0-candidate-2-src.tar.gz
> > >
> > > Best,
> > >
> > > Xiaolong Ran
> > >
> >

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Lari Hotari]

We could all have our own favorite names for this work. :)

There's advice that you should disrupt yourself before someone disrupts you.
Shouldn't we follow that advice for Apache Pulsar? We can disrupt Pulsar 
together with our Apache hats on. The catch is that since we are doing this, we 
will be able to learn and improve Pulsar so that we stay ahead of competition. 
Pulsar was long ways ahead of competition for so many years, but Kafka is 
finally catching up. Did Kafka surpass Pulsar in some aspects with the recent 
3.3 release, where Kraft became GA? That's a question that many might be 
asking. Why wouldn't we rev up Pulsar's engine and show the tail lights to 
Kafka?

We don't have to have deadlines or any restrictions like that right now. The 
sky's the limit.
Linus Torvalds has written a book called "Just for fun". I got my copy of this 
book signed by Linus himself in year 2000 at an event that the book publisher 
had organized in Finland.

What if we did this "just for fun"? The intention could also be to beat Kafka, 
but that could be a boring goal for many. What if we could unleash some talent 
that is among us and hasn't had a chance to show its full potential? Opensource 
is about joy. It is about welcoming everyone to join. Opensource should be 
egoless, although we must all admit that we don't succeed in that aspect. We 
must fight our biases.

Jarek Potiuk explains the importance of being welcoming for success at Apache, 
in a 3-minute YouTube interview:
https://www.youtube.com/watch?v=Dx5kQnVFo7E
This interview is about Jarek's blog post "Success at Apache: Welcoming 
communities strengthens the Apache way":
https://news.apache.org/foundation/entry/success-at-apache-welcoming-communities
 
I was pleased to meet Jarek at ApacheCon among so many other welcoming 
personalities of the Apache community and the Apache Pulsar community.

Goals have to be ambitious. What if we set the bar really high?
Apache Pulsar with 10 million topics in a cluster?
Why not go up to 100 million topics?
Just for fun. :)

-Lari

On 2022/10/07 22:53:59 Matteo Merli wrote:
> I actually disagree with the term "Pulsar Next Gen", because I haven't
> seen any proposal for which that would make sense to me to be called
> so.
> 
> Rajan: That's the whole point of breaking it down. If you accumulate
> many "big" changes it introduces a lot of risk for instabilities and
> incompatibilities. Breaking it down in multiple steps helps to see the
> incremental changes and introduced them in a phased manner.
> 
> 
> -- 
> Matteo Merli
> 
> 
> On Fri, Oct 7, 2022 at 3:37 PM Rajan Dhabalia  wrote:
> >
> > Hi,
> >
> > Can we get the list of changes at one place which we are planning to get as
> > part of 3.0. One thing I would like to see as a part of a major release, it
> > CAN NOT impact existing usecases and users in any way which can force them
> > to upgrade the client library. Applications using < 3.0 version should
> > continue getting all the client and server side enhancements and bug fixes.
> > Failing to provide bug-fixes and features to client < 3.0 means we are
> > forcing them to upgrade client version by putting efforts to handle all
> > incompatibility. and that's something we should definitely prevent because
> > Apache Pulsar is used by many large scale business usecases and we should
> > accommodate and motivate them to continue using Apache Pulsar.
> > I understand as a Pulsar community we should always try to progress and
> > build better but not at the cost of losing or reducing the Apache Pulsar
> > community.
> >
> > Thanks,
> > Rajan
> >
> >
> > On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:
> >
> > > Thank you, Matteo. I agree that features should be delivered continuously
> > > when that is possible. In this case, that might not apply.
> > >
> > > I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
> > > PIP-175 since an LTS release is when the major version is bumped. I'm fine
> > > in calling this "Pulsar Next Gen" or something that calls out that this is
> > > planning for making a major leap in Pulsar.
> > >
> > > There are several unresolved issues with PIP-45 and the Pulsar Load
> > > balancer. The previously referred email threads contain a lot of context 
> > > to
> > > this. Resolving the issues efficiently will most likely result in breaking
> > > changes, which will be the reason why it deserves a major version upgrade.
> > >
> > > We have discussed it before that it's crucial to have a path to migrate
> > > users when there are breaking changes. This should be covered in any of 
> > > the
> > > solutions that are introduced. Optimally, users of Pulsar would be able to
> > > upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
> > > not be directly supported.
> > >
> > > I am welcoming everyone to join this planning for the Apache Pulsar Next
> > > Gen architecture. Please check the first email in this thread for details
> > > of context, and 

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Dave Fisher]

Hi Matteo,

Thank you for this critical work pulling the C++ (and Python) clients out of 
the main repository and into separate repositories and release cycles! I think 
this will be a significant benefit for the community.

All the best,
Dave

Sent from my iPhone

> On Oct 6, 2022, at 1:07 PM, Matteo Merli  wrote:
> 
> We have moved the C++ client to its own separate repo
> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
> 
> There are several new features and fixes in the main branch that it
> would be good to get released, as well to get the new release process
> all flushed out.
> 
> Matteo
> 
> 
> --
> Matteo Merli
> 

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Jiaqi Shen]

+1

Thanks,
Jiaqi Shen


Xiangying Meng  于2022年10月8日周六 10:17写道：

> +1
>
> Thanks,
> Xiangying
>
>
> On Sat, Oct 8, 2022 at 9:43 AM Hang Chen  wrote:
>
> > +1
> >
> > Thanks,
> > Hang
> >
> > Zike Yang  于2022年10月8日周六 09:19写道：
> > >
> > > +1
> > >
> > > Thanks,
> > > Zike Yang
> > >
> > > On Sat, Oct 8, 2022 at 9:17 AM PengHui Li  wrote:
> > > >
> > > > +1
> > > >
> > > > Regards,
> > > > Penghui
> > > >
> > > > On Fri, Oct 7, 2022 at 11:34 PM tison  wrote:
> > > >
> > > > > +1 cool!
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > >
> > > > > Baodi Shi  于2022年10月7日周五 23:31写道：
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Thanks,
> > > > > > Baodi Shi
> > > > > >
> > > > > > > 在 2022年10月7日，22:00，Max Xu  写道：
> > > > > > >
> > > > > > > +1
> > > > > > > Thanks, Matteo. It's a great work!
> > > > > > >
> > > > > > > Best,
> > > > > > > Max Xu
> > > > > > >
> > > > > > >
> > > > > > >> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli <
> mme...@apache.org>
> > > > > wrote:
> > > > > > >>
> > > > > > >> We have moved the C++ client to its own separate repo
> > > > > > >> (https://github.com/apache/pulsar-client-cpp) as part of
> > PIP-209.
> > > > > > >>
> > > > > > >> There are several new features and fixes in the main branch
> > that it
> > > > > > >> would be good to get released, as well to get the new release
> > process
> > > > > > >> all flushed out.
> > > > > > >>
> > > > > > >> Matteo
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Matteo Merli
> > > > > > >> 
> > > > > > >>
> > > > > >
> > > > >
> >
>

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Xiangying Meng]

+1

Thanks,
Xiangying


On Sat, Oct 8, 2022 at 9:43 AM Hang Chen  wrote:

> +1
>
> Thanks,
> Hang
>
> Zike Yang  于2022年10月8日周六 09:19写道：
> >
> > +1
> >
> > Thanks,
> > Zike Yang
> >
> > On Sat, Oct 8, 2022 at 9:17 AM PengHui Li  wrote:
> > >
> > > +1
> > >
> > > Regards,
> > > Penghui
> > >
> > > On Fri, Oct 7, 2022 at 11:34 PM tison  wrote:
> > >
> > > > +1 cool!
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > >
> > > > Baodi Shi  于2022年10月7日周五 23:31写道：
> > > >
> > > > > +1
> > > > >
> > > > > Thanks,
> > > > > Baodi Shi
> > > > >
> > > > > > 在 2022年10月7日，22:00，Max Xu  写道：
> > > > > >
> > > > > > +1
> > > > > > Thanks, Matteo. It's a great work!
> > > > > >
> > > > > > Best,
> > > > > > Max Xu
> > > > > >
> > > > > >
> > > > > >> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli 
> > > > wrote:
> > > > > >>
> > > > > >> We have moved the C++ client to its own separate repo
> > > > > >> (https://github.com/apache/pulsar-client-cpp) as part of
> PIP-209.
> > > > > >>
> > > > > >> There are several new features and fixes in the main branch
> that it
> > > > > >> would be good to get released, as well to get the new release
> process
> > > > > >> all flushed out.
> > > > > >>
> > > > > >> Matteo
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Matteo Merli
> > > > > >> 
> > > > > >>
> > > > >
> > > >
>

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Hang Chen]

+1

Thanks,
Hang

Zike Yang  于2022年10月8日周六 09:19写道：
>
> +1
>
> Thanks,
> Zike Yang
>
> On Sat, Oct 8, 2022 at 9:17 AM PengHui Li  wrote:
> >
> > +1
> >
> > Regards,
> > Penghui
> >
> > On Fri, Oct 7, 2022 at 11:34 PM tison  wrote:
> >
> > > +1 cool!
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Baodi Shi  于2022年10月7日周五 23:31写道：
> > >
> > > > +1
> > > >
> > > > Thanks,
> > > > Baodi Shi
> > > >
> > > > > 在 2022年10月7日，22:00，Max Xu  写道：
> > > > >
> > > > > +1
> > > > > Thanks, Matteo. It's a great work!
> > > > >
> > > > > Best,
> > > > > Max Xu
> > > > >
> > > > >
> > > > >> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli 
> > > wrote:
> > > > >>
> > > > >> We have moved the C++ client to its own separate repo
> > > > >> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
> > > > >>
> > > > >> There are several new features and fixes in the main branch that it
> > > > >> would be good to get released, as well to get the new release process
> > > > >> all flushed out.
> > > > >>
> > > > >> Matteo
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Matteo Merli
> > > > >> 
> > > > >>
> > > >
> > >

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Lari Hotari]

Thank you Rajan for explaining the crucial importance of client compatibility 
in a very clear way. Ensuring client compatibility is a "must" requirement.

We happened to have some discussions about this topic at ApacheCon, and how to 
ensure protocol compatibility in the cases where there would be a need to move 
forward with the protocol to add an important new feature.

The use case for this is Pulsar load balancing without any interruptions for 
producers and clients, thus a transparent handover of topics across brokers. 
This would require Pulsar protocol changes, and that is a problem for existing 
clients. We accepted this challenge and brainstormed.

In this discussion, Chris Bartholomew introduced us to a genius idea: to have a 
proxy layer which supports the older protocol version and which adapts to any 
newer protocol version that contains some advanced features such as transparent 
handover for load balancing a topic across brokers. There could also be 
additional features, such as minimizing TCP/IP reconnects during topic unloads 
and making those completely transparent for clients that don't currently 
tolerate that properly (some existing Golang client versions). This additional 
feature could be controlled in some way.

We evolved this idea together further and came up with the idea that this proxy 
layer could be a built-in part of the brokers themselves. 

This story that happened at a ApacheCon lunch is a good example how we are much 
greater together as a community than working independently in isolation. I'm 
really excited to have more Pulsar enthusiasts join this journey of 
co-creation. It is super fun!

BR,

-Lari 

On 2022/10/07 22:37:19 Rajan Dhabalia wrote:
> Hi,
> 
> Can we get the list of changes at one place which we are planning to get as
> part of 3.0. One thing I would like to see as a part of a major release, it
> CAN NOT impact existing usecases and users in any way which can force them
> to upgrade the client library. Applications using < 3.0 version should
> continue getting all the client and server side enhancements and bug fixes.
> Failing to provide bug-fixes and features to client < 3.0 means we are
> forcing them to upgrade client version by putting efforts to handle all
> incompatibility. and that's something we should definitely prevent because
> Apache Pulsar is used by many large scale business usecases and we should
> accommodate and motivate them to continue using Apache Pulsar.
> I understand as a Pulsar community we should always try to progress and
> build better but not at the cost of losing or reducing the Apache Pulsar
> community.
> 
> Thanks,
> Rajan
> 
> 
> On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:
> 
> > Thank you, Matteo. I agree that features should be delivered continuously
> > when that is possible. In this case, that might not apply.
> >
> > I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
> > PIP-175 since an LTS release is when the major version is bumped. I'm fine
> > in calling this "Pulsar Next Gen" or something that calls out that this is
> > planning for making a major leap in Pulsar.
> >
> > There are several unresolved issues with PIP-45 and the Pulsar Load
> > balancer. The previously referred email threads contain a lot of context to
> > this. Resolving the issues efficiently will most likely result in breaking
> > changes, which will be the reason why it deserves a major version upgrade.
> >
> > We have discussed it before that it's crucial to have a path to migrate
> > users when there are breaking changes. This should be covered in any of the
> > solutions that are introduced. Optimally, users of Pulsar would be able to
> > upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
> > not be directly supported.
> >
> > I am welcoming everyone to join this planning for the Apache Pulsar Next
> > Gen architecture. Please check the first email in this thread for details
> > of context, and start participating and contributing today. The best way to
> > contribute is to participate in the email threads, since they contain
> > details with better context.
> >
> > -Lari
> >
> > On 2022/10/07 18:03:00 Matteo Merli wrote:
> > > Given the past experiences and the discussions that already happened
> > > around "PIP-175: Extend time based release process", the idea is to
> > > detach the 3.0 from "big-features" items or "incompatible changes".
> > >
> > > The changes are going to get included as they are ready, within
> > > feature releases, and in a fully compatible way. We don't need to
> > > group them together and create unnecessary risk for the release
> > > schedule and the users.
> > >
> > >
> > > --
> > > Matteo Merli
> > > 
> > >
> > > On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Greeting from ApacheCon North America 2022 from New Orleans!
> > > > We had a great conference with a dedicated Pulsar track. Thanks to all
> > presenters 

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Dave Fisher]

To me the point of this discussion is for the community to discuss both 
improvement ideas along with current pain points in the broker. Whether or not 
the ideas and proposed solutions are breaking or incremental is yet to be 
determined. Let’s not get hung up on versions or nomenclature.

All the best,
Dave

Sent from my iPhone

> On Oct 7, 2022, at 5:54 PM, Matteo Merli  wrote:
> 
> I actually disagree with the term "Pulsar Next Gen", because I haven't
> seen any proposal for which that would make sense to me to be called
> so.
> 
> Rajan: That's the whole point of breaking it down. If you accumulate
> many "big" changes it introduces a lot of risk for instabilities and
> incompatibilities. Breaking it down in multiple steps helps to see the
> incremental changes and introduced them in a phased manner.
> 
> 
> -- 
> Matteo Merli
> 
> 
>> On Fri, Oct 7, 2022 at 3:37 PM Rajan Dhabalia  wrote:
>> 
>> Hi,
>> 
>> Can we get the list of changes at one place which we are planning to get as
>> part of 3.0. One thing I would like to see as a part of a major release, it
>> CAN NOT impact existing usecases and users in any way which can force them
>> to upgrade the client library. Applications using < 3.0 version should
>> continue getting all the client and server side enhancements and bug fixes.
>> Failing to provide bug-fixes and features to client < 3.0 means we are
>> forcing them to upgrade client version by putting efforts to handle all
>> incompatibility. and that's something we should definitely prevent because
>> Apache Pulsar is used by many large scale business usecases and we should
>> accommodate and motivate them to continue using Apache Pulsar.
>> I understand as a Pulsar community we should always try to progress and
>> build better but not at the cost of losing or reducing the Apache Pulsar
>> community.
>> 
>> Thanks,
>> Rajan
>> 
>> 
>>> On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:
>>> 
>>> Thank you, Matteo. I agree that features should be delivered continuously
>>> when that is possible. In this case, that might not apply.
>>> 
>>> I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
>>> PIP-175 since an LTS release is when the major version is bumped. I'm fine
>>> in calling this "Pulsar Next Gen" or something that calls out that this is
>>> planning for making a major leap in Pulsar.
>>> 
>>> There are several unresolved issues with PIP-45 and the Pulsar Load
>>> balancer. The previously referred email threads contain a lot of context to
>>> this. Resolving the issues efficiently will most likely result in breaking
>>> changes, which will be the reason why it deserves a major version upgrade.
>>> 
>>> We have discussed it before that it's crucial to have a path to migrate
>>> users when there are breaking changes. This should be covered in any of the
>>> solutions that are introduced. Optimally, users of Pulsar would be able to
>>> upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
>>> not be directly supported.
>>> 
>>> I am welcoming everyone to join this planning for the Apache Pulsar Next
>>> Gen architecture. Please check the first email in this thread for details
>>> of context, and start participating and contributing today. The best way to
>>> contribute is to participate in the email threads, since they contain
>>> details with better context.
>>> 
>>> -Lari
>>> 
>>> On 2022/10/07 18:03:00 Matteo Merli wrote:
 Given the past experiences and the discussions that already happened
 around "PIP-175: Extend time based release process", the idea is to
 detach the 3.0 from "big-features" items or "incompatible changes".
 
 The changes are going to get included as they are ready, within
 feature releases, and in a fully compatible way. We don't need to
 group them together and create unnecessary risk for the release
 schedule and the users.
 
 
 --
 Matteo Merli
 
 
 On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
> 
> Hi all,
> 
> Greeting from ApacheCon North America 2022 from New Orleans!
> We had a great conference with a dedicated Pulsar track. Thanks to all
>>> presenters and everyone who attended. The talks weren't recorded, but the
>>> slides will be later on posted on the conference website [1].
> 
> At ApacheCon there were several presentations about "the Apache way"
>>> and what that means in practice. Based on that, we all know that no person
>>> is nominated as the CTO of Apache Pulsar who decides on Pulsar 3.0 and when
>>> that happens. It's us, the community, that serve that role together. We
>>> come together as individuals with the Apache hat on. Everyone is equal in
>>> the community, regardless of whether they are contributors, committers or
>>> PMC members.
> We welcome everyone to participate. The small detail about voting
>>> shouldn't stop anyone from participating in any aspects of the planning for
>>> the roadmap.

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Zike Yang]

+1

Thanks,
Zike Yang

On Sat, Oct 8, 2022 at 9:17 AM PengHui Li  wrote:
>
> +1
>
> Regards,
> Penghui
>
> On Fri, Oct 7, 2022 at 11:34 PM tison  wrote:
>
> > +1 cool!
> >
> > Best,
> > tison.
> >
> >
> > Baodi Shi  于2022年10月7日周五 23:31写道：
> >
> > > +1
> > >
> > > Thanks,
> > > Baodi Shi
> > >
> > > > 在 2022年10月7日，22:00，Max Xu  写道：
> > > >
> > > > +1
> > > > Thanks, Matteo. It's a great work!
> > > >
> > > > Best,
> > > > Max Xu
> > > >
> > > >
> > > >> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli 
> > wrote:
> > > >>
> > > >> We have moved the C++ client to its own separate repo
> > > >> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
> > > >>
> > > >> There are several new features and fixes in the main branch that it
> > > >> would be good to get released, as well to get the new release process
> > > >> all flushed out.
> > > >>
> > > >> Matteo
> > > >>
> > > >>
> > > >> --
> > > >> Matteo Merli
> > > >> 
> > > >>
> > >
> >

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[PengHui Li]

+1

Regards,
Penghui

On Fri, Oct 7, 2022 at 11:34 PM tison  wrote:

> +1 cool!
>
> Best,
> tison.
>
>
> Baodi Shi  于2022年10月7日周五 23:31写道：
>
> > +1
> >
> > Thanks,
> > Baodi Shi
> >
> > > 在 2022年10月7日，22:00，Max Xu  写道：
> > >
> > > +1
> > > Thanks, Matteo. It's a great work!
> > >
> > > Best,
> > > Max Xu
> > >
> > >
> > >> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli 
> wrote:
> > >>
> > >> We have moved the C++ client to its own separate repo
> > >> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
> > >>
> > >> There are several new features and fixes in the main branch that it
> > >> would be good to get released, as well to get the new release process
> > >> all flushed out.
> > >>
> > >> Matteo
> > >>
> > >>
> > >> --
> > >> Matteo Merli
> > >> 
> > >>
> >
>

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Matteo Merli]

I actually disagree with the term "Pulsar Next Gen", because I haven't
seen any proposal for which that would make sense to me to be called
so.

Rajan: That's the whole point of breaking it down. If you accumulate
many "big" changes it introduces a lot of risk for instabilities and
incompatibilities. Breaking it down in multiple steps helps to see the
incremental changes and introduced them in a phased manner.


-- 
Matteo Merli


On Fri, Oct 7, 2022 at 3:37 PM Rajan Dhabalia  wrote:
>
> Hi,
>
> Can we get the list of changes at one place which we are planning to get as
> part of 3.0. One thing I would like to see as a part of a major release, it
> CAN NOT impact existing usecases and users in any way which can force them
> to upgrade the client library. Applications using < 3.0 version should
> continue getting all the client and server side enhancements and bug fixes.
> Failing to provide bug-fixes and features to client < 3.0 means we are
> forcing them to upgrade client version by putting efforts to handle all
> incompatibility. and that's something we should definitely prevent because
> Apache Pulsar is used by many large scale business usecases and we should
> accommodate and motivate them to continue using Apache Pulsar.
> I understand as a Pulsar community we should always try to progress and
> build better but not at the cost of losing or reducing the Apache Pulsar
> community.
>
> Thanks,
> Rajan
>
>
> On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:
>
> > Thank you, Matteo. I agree that features should be delivered continuously
> > when that is possible. In this case, that might not apply.
> >
> > I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
> > PIP-175 since an LTS release is when the major version is bumped. I'm fine
> > in calling this "Pulsar Next Gen" or something that calls out that this is
> > planning for making a major leap in Pulsar.
> >
> > There are several unresolved issues with PIP-45 and the Pulsar Load
> > balancer. The previously referred email threads contain a lot of context to
> > this. Resolving the issues efficiently will most likely result in breaking
> > changes, which will be the reason why it deserves a major version upgrade.
> >
> > We have discussed it before that it's crucial to have a path to migrate
> > users when there are breaking changes. This should be covered in any of the
> > solutions that are introduced. Optimally, users of Pulsar would be able to
> > upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
> > not be directly supported.
> >
> > I am welcoming everyone to join this planning for the Apache Pulsar Next
> > Gen architecture. Please check the first email in this thread for details
> > of context, and start participating and contributing today. The best way to
> > contribute is to participate in the email threads, since they contain
> > details with better context.
> >
> > -Lari
> >
> > On 2022/10/07 18:03:00 Matteo Merli wrote:
> > > Given the past experiences and the discussions that already happened
> > > around "PIP-175: Extend time based release process", the idea is to
> > > detach the 3.0 from "big-features" items or "incompatible changes".
> > >
> > > The changes are going to get included as they are ready, within
> > > feature releases, and in a fully compatible way. We don't need to
> > > group them together and create unnecessary risk for the release
> > > schedule and the users.
> > >
> > >
> > > --
> > > Matteo Merli
> > > 
> > >
> > > On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Greeting from ApacheCon North America 2022 from New Orleans!
> > > > We had a great conference with a dedicated Pulsar track. Thanks to all
> > presenters and everyone who attended. The talks weren't recorded, but the
> > slides will be later on posted on the conference website [1].
> > > >
> > > > At ApacheCon there were several presentations about "the Apache way"
> > and what that means in practice. Based on that, we all know that no person
> > is nominated as the CTO of Apache Pulsar who decides on Pulsar 3.0 and when
> > that happens. It's us, the community, that serve that role together. We
> > come together as individuals with the Apache hat on. Everyone is equal in
> > the community, regardless of whether they are contributors, committers or
> > PMC members.
> > > > We welcome everyone to participate. The small detail about voting
> > shouldn't stop anyone from participating in any aspects of the planning for
> > the roadmap.
> > > >
> > > > I'll like to get the discussions going for Pulsar 3.0. We don't need a
> > separate decision to start planning that. Please correct me if I'm wrong or
> > if you have a different opinion.
> > > >
> > > > There are a few previous discussion threads that are related to Pulsar
> > 3.0 planning.
> > > > If you are interested in getting involved with Apache Pulsar 3.0
> > planning, I think that it makes sense for you to 

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Rajan Dhabalia]

Hi,

Can we get the list of changes at one place which we are planning to get as
part of 3.0. One thing I would like to see as a part of a major release, it
CAN NOT impact existing usecases and users in any way which can force them
to upgrade the client library. Applications using < 3.0 version should
continue getting all the client and server side enhancements and bug fixes.
Failing to provide bug-fixes and features to client < 3.0 means we are
forcing them to upgrade client version by putting efforts to handle all
incompatibility. and that's something we should definitely prevent because
Apache Pulsar is used by many large scale business usecases and we should
accommodate and motivate them to continue using Apache Pulsar.
I understand as a Pulsar community we should always try to progress and
build better but not at the cost of losing or reducing the Apache Pulsar
community.

Thanks,
Rajan


On Fri, Oct 7, 2022 at 12:41 PM Lari Hotari  wrote:

> Thank you, Matteo. I agree that features should be delivered continuously
> when that is possible. In this case, that might not apply.
>
> I also agree that calling this Pulsar 3.0 isn't necessarily aligned with
> PIP-175 since an LTS release is when the major version is bumped. I'm fine
> in calling this "Pulsar Next Gen" or something that calls out that this is
> planning for making a major leap in Pulsar.
>
> There are several unresolved issues with PIP-45 and the Pulsar Load
> balancer. The previously referred email threads contain a lot of context to
> this. Resolving the issues efficiently will most likely result in breaking
> changes, which will be the reason why it deserves a major version upgrade.
>
> We have discussed it before that it's crucial to have a path to migrate
> users when there are breaking changes. This should be covered in any of the
> solutions that are introduced. Optimally, users of Pulsar would be able to
> upgrade seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might
> not be directly supported.
>
> I am welcoming everyone to join this planning for the Apache Pulsar Next
> Gen architecture. Please check the first email in this thread for details
> of context, and start participating and contributing today. The best way to
> contribute is to participate in the email threads, since they contain
> details with better context.
>
> -Lari
>
> On 2022/10/07 18:03:00 Matteo Merli wrote:
> > Given the past experiences and the discussions that already happened
> > around "PIP-175: Extend time based release process", the idea is to
> > detach the 3.0 from "big-features" items or "incompatible changes".
> >
> > The changes are going to get included as they are ready, within
> > feature releases, and in a fully compatible way. We don't need to
> > group them together and create unnecessary risk for the release
> > schedule and the users.
> >
> >
> > --
> > Matteo Merli
> > 
> >
> > On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
> > >
> > > Hi all,
> > >
> > > Greeting from ApacheCon North America 2022 from New Orleans!
> > > We had a great conference with a dedicated Pulsar track. Thanks to all
> presenters and everyone who attended. The talks weren't recorded, but the
> slides will be later on posted on the conference website [1].
> > >
> > > At ApacheCon there were several presentations about "the Apache way"
> and what that means in practice. Based on that, we all know that no person
> is nominated as the CTO of Apache Pulsar who decides on Pulsar 3.0 and when
> that happens. It's us, the community, that serve that role together. We
> come together as individuals with the Apache hat on. Everyone is equal in
> the community, regardless of whether they are contributors, committers or
> PMC members.
> > > We welcome everyone to participate. The small detail about voting
> shouldn't stop anyone from participating in any aspects of the planning for
> the roadmap.
> > >
> > > I'll like to get the discussions going for Pulsar 3.0. We don't need a
> separate decision to start planning that. Please correct me if I'm wrong or
> if you have a different opinion.
> > >
> > > There are a few previous discussion threads that are related to Pulsar
> 3.0 planning.
> > > If you are interested in getting involved with Apache Pulsar 3.0
> planning, I think that it makes sense for you to read these threads
> carefully and reply to them. Please also suggest what you think makes sense.
> > >
> > > PIP-45 related:
> https://lists.apache.org/thread/tvco1orf0hsyt59pjtfbwoq0vf6hfrcj
> > > Pulsar Load balancer / namespace bundle related:
> > > https://lists.apache.org/thread/roohoc9h2gthvmd7t81do4hfjs2gphpk
> > > renaming topics:
> > > https://lists.apache.org/thread/vrr75rrh4trqlp14objh3snlfvmzdrp2
> > > backpressure:
> https://lists.apache.org/thread/v7xy57qfzbhopoqbm75s6ng8xlhbr2q6
> > >
> > > Long list of Metadata inconsistency issues by Zac Bentley:
> > > https://github.com/apache/pulsar/issues/12555
> > > That would be a good starting point to 

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Lari Hotari]

Thank you, Matteo. I agree that features should be delivered continuously when 
that is possible. In this case, that might not apply. 

I also agree that calling this Pulsar 3.0 isn't necessarily aligned with 
PIP-175 since an LTS release is when the major version is bumped. I'm fine in 
calling this "Pulsar Next Gen" or something that calls out that this is 
planning for making a major leap in Pulsar. 

There are several unresolved issues with PIP-45 and the Pulsar Load balancer. 
The previously referred email threads contain a lot of context to this. 
Resolving the issues efficiently will most likely result in breaking changes, 
which will be the reason why it deserves a major version upgrade.

We have discussed it before that it's crucial to have a path to migrate users 
when there are breaking changes. This should be covered in any of the solutions 
that are introduced. Optimally, users of Pulsar would be able to upgrade 
seamlessly to Pulsar Next Gen / Pulsar 3.0, but rolling back might not be 
directly supported. 

I am welcoming everyone to join this planning for the Apache Pulsar Next Gen 
architecture. Please check the first email in this thread for details of 
context, and start participating and contributing today. The best way to 
contribute is to participate in the email threads, since they contain details 
with better context.

-Lari

On 2022/10/07 18:03:00 Matteo Merli wrote:
> Given the past experiences and the discussions that already happened
> around "PIP-175: Extend time based release process", the idea is to
> detach the 3.0 from "big-features" items or "incompatible changes".
> 
> The changes are going to get included as they are ready, within
> feature releases, and in a fully compatible way. We don't need to
> group them together and create unnecessary risk for the release
> schedule and the users.
> 
> 
> --
> Matteo Merli
> 
> 
> On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
> >
> > Hi all,
> >
> > Greeting from ApacheCon North America 2022 from New Orleans!
> > We had a great conference with a dedicated Pulsar track. Thanks to all 
> > presenters and everyone who attended. The talks weren't recorded, but the 
> > slides will be later on posted on the conference website [1].
> >
> > At ApacheCon there were several presentations about "the Apache way" and 
> > what that means in practice. Based on that, we all know that no person is 
> > nominated as the CTO of Apache Pulsar who decides on Pulsar 3.0 and when 
> > that happens. It's us, the community, that serve that role together. We 
> > come together as individuals with the Apache hat on. Everyone is equal in 
> > the community, regardless of whether they are contributors, committers or 
> > PMC members.
> > We welcome everyone to participate. The small detail about voting shouldn't 
> > stop anyone from participating in any aspects of the planning for the 
> > roadmap.
> >
> > I'll like to get the discussions going for Pulsar 3.0. We don't need a 
> > separate decision to start planning that. Please correct me if I'm wrong or 
> > if you have a different opinion.
> >
> > There are a few previous discussion threads that are related to Pulsar 3.0 
> > planning.
> > If you are interested in getting involved with Apache Pulsar 3.0 planning, 
> > I think that it makes sense for you to read these threads carefully and 
> > reply to them. Please also suggest what you think makes sense.
> >
> > PIP-45 related: 
> > https://lists.apache.org/thread/tvco1orf0hsyt59pjtfbwoq0vf6hfrcj
> > Pulsar Load balancer / namespace bundle related:
> > https://lists.apache.org/thread/roohoc9h2gthvmd7t81do4hfjs2gphpk
> > renaming topics:
> > https://lists.apache.org/thread/vrr75rrh4trqlp14objh3snlfvmzdrp2
> > backpressure: 
> > https://lists.apache.org/thread/v7xy57qfzbhopoqbm75s6ng8xlhbr2q6
> >
> > Long list of Metadata inconsistency issues by Zac Bentley:
> > https://github.com/apache/pulsar/issues/12555
> > That would be a good starting point to understanding the data inconsistency 
> > issues related to current PIP-45 design. Perhaps those could be addressed 
> > already before Pulsar 3.0?
> >
> > I'm looking forward to everyone's participation in the Apache Pulsar 3.0 
> > planning discussions.
> >
> > Best Regards,
> >
> > -Lari
> >
> > 1 - https://www.apachecon.com/acna2022/schedule.html
> 

Re: [DISCUSS] Planning for Apache Pulsar 3.0

[Matteo Merli]

Given the past experiences and the discussions that already happened
around "PIP-175: Extend time based release process", the idea is to
detach the 3.0 from "big-features" items or "incompatible changes".

The changes are going to get included as they are ready, within
feature releases, and in a fully compatible way. We don't need to
group them together and create unnecessary risk for the release
schedule and the users.


--
Matteo Merli


On Fri, Oct 7, 2022 at 10:47 AM Lari Hotari  wrote:
>
> Hi all,
>
> Greeting from ApacheCon North America 2022 from New Orleans!
> We had a great conference with a dedicated Pulsar track. Thanks to all 
> presenters and everyone who attended. The talks weren't recorded, but the 
> slides will be later on posted on the conference website [1].
>
> At ApacheCon there were several presentations about "the Apache way" and what 
> that means in practice. Based on that, we all know that no person is 
> nominated as the CTO of Apache Pulsar who decides on Pulsar 3.0 and when that 
> happens. It's us, the community, that serve that role together. We come 
> together as individuals with the Apache hat on. Everyone is equal in the 
> community, regardless of whether they are contributors, committers or PMC 
> members.
> We welcome everyone to participate. The small detail about voting shouldn't 
> stop anyone from participating in any aspects of the planning for the roadmap.
>
> I'll like to get the discussions going for Pulsar 3.0. We don't need a 
> separate decision to start planning that. Please correct me if I'm wrong or 
> if you have a different opinion.
>
> There are a few previous discussion threads that are related to Pulsar 3.0 
> planning.
> If you are interested in getting involved with Apache Pulsar 3.0 planning, I 
> think that it makes sense for you to read these threads carefully and reply 
> to them. Please also suggest what you think makes sense.
>
> PIP-45 related: 
> https://lists.apache.org/thread/tvco1orf0hsyt59pjtfbwoq0vf6hfrcj
> Pulsar Load balancer / namespace bundle related:
> https://lists.apache.org/thread/roohoc9h2gthvmd7t81do4hfjs2gphpk
> renaming topics:
> https://lists.apache.org/thread/vrr75rrh4trqlp14objh3snlfvmzdrp2
> backpressure: https://lists.apache.org/thread/v7xy57qfzbhopoqbm75s6ng8xlhbr2q6
>
> Long list of Metadata inconsistency issues by Zac Bentley:
> https://github.com/apache/pulsar/issues/12555
> That would be a good starting point to understanding the data inconsistency 
> issues related to current PIP-45 design. Perhaps those could be addressed 
> already before Pulsar 3.0?
>
> I'm looking forward to everyone's participation in the Apache Pulsar 3.0 
> planning discussions.
>
> Best Regards,
>
> -Lari
>
> 1 - https://www.apachecon.com/acna2022/schedule.html

[DISCUSS] Planning for Apache Pulsar 3.0

[Lari Hotari]

Hi all, 

Greeting from ApacheCon North America 2022 from New Orleans! 
We had a great conference with a dedicated Pulsar track. Thanks to all 
presenters and everyone who attended. The talks weren't recorded, but the 
slides will be later on posted on the conference website [1].

At ApacheCon there were several presentations about "the Apache way" and what 
that means in practice. Based on that, we all know that no person is nominated 
as the CTO of Apache Pulsar who decides on Pulsar 3.0 and when that happens. 
It's us, the community, that serve that role together. We come together as 
individuals with the Apache hat on. Everyone is equal in the community, 
regardless of whether they are contributors, committers or PMC members. 
We welcome everyone to participate. The small detail about voting shouldn't 
stop anyone from participating in any aspects of the planning for the roadmap.

I'll like to get the discussions going for Pulsar 3.0. We don't need a separate 
decision to start planning that. Please correct me if I'm wrong or if you have 
a different opinion.

There are a few previous discussion threads that are related to Pulsar 3.0 
planning. 
If you are interested in getting involved with Apache Pulsar 3.0 planning, I 
think that it makes sense for you to read these threads carefully and reply to 
them. Please also suggest what you think makes sense.

PIP-45 related: https://lists.apache.org/thread/tvco1orf0hsyt59pjtfbwoq0vf6hfrcj
Pulsar Load balancer / namespace bundle related:
https://lists.apache.org/thread/roohoc9h2gthvmd7t81do4hfjs2gphpk
renaming topics:
https://lists.apache.org/thread/vrr75rrh4trqlp14objh3snlfvmzdrp2
backpressure: https://lists.apache.org/thread/v7xy57qfzbhopoqbm75s6ng8xlhbr2q6

Long list of Metadata inconsistency issues by Zac Bentley:
https://github.com/apache/pulsar/issues/12555
That would be a good starting point to understanding the data inconsistency 
issues related to current PIP-45 design. Perhaps those could be addressed 
already before Pulsar 3.0?

I'm looking forward to everyone's participation in the Apache Pulsar 3.0 
planning discussions.

Best Regards,

-Lari

1 - https://www.apachecon.com/acna2022/schedule.html

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[tison]

+1 cool!

Best,
tison.


Baodi Shi  于2022年10月7日周五 23:31写道：

> +1
>
> Thanks,
> Baodi Shi
>
> > 在 2022年10月7日，22:00，Max Xu  写道：
> >
> > +1
> > Thanks, Matteo. It's a great work!
> >
> > Best,
> > Max Xu
> >
> >
> >> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli  wrote:
> >>
> >> We have moved the C++ client to its own separate repo
> >> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
> >>
> >> There are several new features and fixes in the main branch that it
> >> would be good to get released, as well to get the new release process
> >> all flushed out.
> >>
> >> Matteo
> >>
> >>
> >> --
> >> Matteo Merli
> >> 
> >>
>

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Baodi Shi]

+1

Thanks,
Baodi Shi

> 在 2022年10月7日，22:00，Max Xu  写道：
> 
> +1
> Thanks, Matteo. It's a great work!
> 
> Best,
> Max Xu
> 
> 
>> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli  wrote:
>> 
>> We have moved the C++ client to its own separate repo
>> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
>> 
>> There are several new features and fixes in the main branch that it
>> would be good to get released, as well to get the new release process
>> all flushed out.
>> 
>> Matteo
>> 
>> 
>> --
>> Matteo Merli
>> 
>> 

[GitHub] [pulsar-helm-chart] tisonkun commented on issue #290: Release Pulsar Helm Chart in GitHub Pages flavor

[GitBox]

tisonkun commented on issue #290:
URL: 
https://github.com/apache/pulsar-helm-chart/issues/290#issuecomment-1271745474

   Thanks for your feedback @michaeljmarshall @ericsyh @yaalsn. Sorry for the 
late reply.
   
   Although any Apache TLP needs not to follow approaches adopted by other 
projects, I try to see how other projects do it:
   
   CouchDB, APISIX, and ShenYu use the GitHub Actions + GitHub Pages way.
   
   * 
https://github.com/apache/couchdb-helm/blob/main/.github/workflows/chart-releaser.yaml
   * 
https://github.com/apache/apisix-helm-chart/blob/master/.github/workflows/release.yaml
   * 
https://github.com/apache/shenyu-helm-chart/blob/main/.github/workflows/release.yml
   
   SkyWalking and Tika publish the Chart to https://apache.jfrog.io. I don't 
find the release manual yet.
   
   * https://github.com/apache/skywalking-kubernetes
   * https://github.com/apache/tika-helm
   
   @michaeljmarshall I ever thought of the release process based on dist.a.o. 
But thinking once more about the archive policy and upload process I tend to 
avoid them if we can.
   
   Thus, I'd like to continue to introduce the GitHub Pages flavor release. 
@michaeljmarshall does it make sense to you?
   
   Related actions have been added to whitelist: 
https://issues.apache.org/jira/browse/INFRA-23716


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Max Xu]

+1
Thanks, Matteo. It's a great work!

Best,
Max Xu


On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli  wrote:

> We have moved the C++ client to its own separate repo
> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
>
> There are several new features and fixes in the main branch that it
> would be good to get released, as well to get the new release process
> all flushed out.
>
> Matteo
>
>
> --
> Matteo Merli
> 
>

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Kai Wang]

+1

Thanks,
Kai
On Oct 7, 2022, 2:07 AM +0800, Matteo Merli , wrote:
> We have moved the C++ client to its own separate repo
> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
>
> There are several new features and fixes in the main branch that it
> would be good to get released, as well to get the new release process
> all flushed out.
>
> Matteo
>
>
> --
> Matteo Merli
> 

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Yunze Xu]

+1

Thanks,
Yunze




> On Oct 7, 2022, at 02:07, Matteo Merli  wrote:
> 
> We have moved the C++ client to its own separate repo
> (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
> 
> There are several new features and fixes in the main branch that it
> would be good to get released, as well to get the new release process
> all flushed out.
> 
> Matteo
> 
> 
> --
> Matteo Merli
> 

Re:[VOTE] Pulsar Release 2.10.2 Candidate 2

[Lan Liang]

+1, non-binding


Checked;
- Checksum 
- Run standalone from apache-pulsar-2.10.2-bin.tar.gz and produce-consume from 
client-go
- Run standalone from container image of jason918/pulsar:2.10.2 and 
produce-consume from client-go






Best Regards,
Lan Liang


 Replied Message 
| From | Haiting Jiang |
| Date | 10/6/2022 10:46 |
| To |  |
| Subject | [VOTE] Pulsar Release 2.10.2 Candidate 2 |
This is the second release candidate for Apache Pulsar, version 2.10.2.

This release contains 249 commits by 57 contributors.
https://github.com/apache/pulsar/compare/v2.10.1...v2.10.2-candidate-2

CI for this release candidate
https://github.com/Jason918/pulsar/pull/10

*** Please download, test and vote on this release. This vote will stay open
for at least 72 hours ***

Note that we are voting upon the source (tag), binaries are provided for
convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.2-candidate-2/

SHA-512 checksums:
26dc11e1514aa286d934e2f9698f4a04def6424307dcc452324bf935e88ba97c2d75b480a88a98640010c0117293d128e389c3e4fa98ab51cfc19e9312f5d00a
./apache-pulsar-2.10.2-bin.tar.gz
0eee2f47680966736acbdbdf309b0c7ccd4d10f737f49b6b8d9f5599a51d46568c1a0a18c75be6a44f78da60fe4287889d2e158fe530b20cee8b64411abe65f0
./apache-pulsar-2.10.2-src.tar.gz

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1186/

The tag to be voted upon:
v2.10.2-candidate-2 (850c9448a5ac32e2f94988b8bf80955c93ef9d6c)
https://github.com/apache/pulsar/releases/tag/v2.10.2-candidate-2

Pulsar's KEYS file containing PGP keys we use to sign the release:
https://dist.apache.org/repos/dist/dev/pulsar/KEYS

Docker images:
https://hub.docker.com/layers/jason918/pulsar/2.10.2/images/sha256-1ef93f17102e8193fc625fd5572f431d45935f7e2f11add3725a301c4321cef4
https://hub.docker.com/layers/jason918/pulsar-all/2.10.2/images/sha256-6e6b49687b7debdf26feb71fedaa622de425885de5e2e7498dc476867cab85bc

Please download the source package, and follow the
release-candidate-validation doc to build
and run the Pulsar standalone service.
https://github.com/apache/pulsar/blob/master/wiki/release/release-candidate-validation.md

Thanks,
Haiting

Re: [DISCUSS] Release Pulsar Client C++ 3.0.0

[Zixuan Liu]

+1.

Zixuan

Enrico Olivelli  于2022年10月7日周五 03:55写道：

> Sure!
>
>
> Enrico
>
> Il Gio 6 Ott 2022, 20:07 Matteo Merli  ha scritto:
>
> > We have moved the C++ client to its own separate repo
> > (https://github.com/apache/pulsar-client-cpp) as part of PIP-209.
> >
> > There are several new features and fixes in the main branch that it
> > would be good to get released, as well to get the new release process
> > all flushed out.
> >
> > Matteo
> >
> >
> > --
> > Matteo Merli
> > 
> >
>