Proper Version Control

[DonghunLouisLee]

Since pulsar-rs currently does not have proper version control policies, I suggest we move forward with following policies as below

1. Major Update(1.x.x -> 2.x.x) will follow pulsar major version update(2.x.x -> 3.x.x)
2. Minor Update(2.1.x -> 2.2.x) will follow pulsar minor version update(2.1.x -> 2.2.x)
3. Patch Update(2.1.1 -> 2.1.2) will be a collection of necessary updates

For now, since pulsar-rs is INCOMPLETE as it does not support all the features, it would be a good idea to set a target pulsar version that this client library aims to match.

I propose 2.10.x as the target apache version and due date as 2022 Decemeber. Until then, all new features beyond 2.10.x should not be prioritized and PRs should be focused on solving existing bugs and features within 2.10.x.

Once our goal is satisfied, It would be a good idea to follow version control as mentined above though we would have to start from 4.10.x which would be compatible with apache pulsar 2.10.x since this crate has already reached version 4.1.2 as of 2022/08

Following is list of open issues that should be tackled for version fix(list will be updated continuously). Contributors for this crate are strongly encouraged to handle below issues.

1. Authentication
   • Fixed serviceNotReady exception when using oauth2 authentication #221
   • Support for TLS Authentication #197
2. Producer
   • Producer batching should have a time limit #104
   • Producer send incomplete batch after delay #213
3. Consumer
   • BUG，consumer.rs:872:29 attempt to subtract with overflow, #194
   • Consumer gets stuck indefinitely in some cases where Pulsar/ZK restarts #189
4. Misc
   • producer->send_raw always wait for receipt when disable batch #171

[tisonkun]

Thanks for starting this discussion @DonghunLouisLee!

Generally, client libraries should be backward compatible during a major version. And I can see that the pulsar crate already takes versions from 0.x to 4.x, including 1.x, 2.x, and 3.x.

I'd prefer to continue the version strategy that releasing the pulsar crate standalone while holds a compatibility matrix as other client libraries do:

• pulsar-client-node
• ruby-kafka

Except Pulsar bumps its major version, its protocol should keep backward compatible. Thus, we don't have to force the rust client to do simultaneous releases with the main repo.

cc @codelipenghui

[tisonkun]

BTW, the Pulsar protocol has a protocol version property to help us determine what features are available in the target cluster.

It helps us do version controlling, like throwing a meaningful error message when features aren't supported in the target cluster or switching different process modules based on different versions. And we don't need to force users to use the client of the correct version to connect to the target cluster.

[tisonkun]

But yes, we can target the next release to be compatible (tested) with Pulsar 2.10.x only, and later extend its compatible matrix, while we may call it 4.2.0 or 5.0.0 :)