On Tue, 14 Jan 2025 at 09:26, Baodi Shi wrote:
>
> hi, @lari and @enrico thanks for discuss.
>
> Yes, I agree that PR 9292 is a useful feature.
>
> https://pulsar.apache.org/contribute/release-policy/#compatibility-between-releases
>
> When I look at our compatibility strategy, what we promised i
hi, @lari and @enrico thanks for discuss.
Yes, I agree that PR 9292 is a useful feature.
https://pulsar.apache.org/contribute/release-policy/#compatibility-between-releases
When I look at our compatibility strategy, what we promised is
compatibility from 3.0 -> 4.0 -> 3.0.
Note that when the d
On Tue, 14 Jan 2025 at 04:05, Baodi Shi wrote:
>
> I believe that in the early stages of a major version, some breaking
> changes are unavoidable. We can't ensure 100% prevention.
>
> However, once an issue arises, we need to fix and resolve it promptly,
> rather than maintaining the breaking chan
On Mon, 13 Jan 2025 at 16:51, Enrico Olivelli wrote:
>
> Given that Pulsar 4.0 has been out for a while and it is considered
> production ready it is better to keep compatibility with Pulsar 4 (set the
> flag to 'true') and document this flag in the release notes or any upgrade
> guide from 3 to 4
+1 (binding)
- Built from source
- Checked the signatures and checksums
- Ran pulsar standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function
Regards
Jiwei Guo (Tboy)
On Tue, Jan 14, 2025 at 9:55 AM Yike Xiao wrote:
> +1 (non-bindi
+1 (binding)
- Built from source
- Checked the signatures and checksums
- Ran pulsar standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function
Regards
Jiwei Guo (Tboy)
On Tue, Jan 14, 2025 at 12:05 AM Yike Xiao wrote:
> +1 (non-bind
+1 (binding)
- Built from source
- Checked the signatures and checksums
- Ran pulsar standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function
Regards
Jiwei Guo (Tboy)
On Tue, Jan 14, 2025 at 12:30 AM Yike Xiao wrote:
> +1 (non-bind
The Apache Pulsar team is proud to announce Apache Pulsar Client C++
version 3.7.0.
Pulsar is a highly scalable, low latency messaging platform running on
commodity hardware. It provides simple pub-sub semantics over topics,
guaranteed at-least-once delivery of messages, automatic cursor managemen
I believe that in the early stages of a major version, some breaking
changes are unavoidable. We can't ensure 100% prevention.
However, once an issue arises, we need to fix and resolve it promptly,
rather than maintaining the breaking change.
In other words, how many users are currently using ver
+1 (non-binding)
- Built from source
- Checked the signatures and checksums of the source and binary release
artifacts
- Ran standalone with etcd metastore
- Ran pulsar standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function
- Ran custom e
+1 (non-binding)
- Built from source
- Checked the signatures of the source and binary release artifacts
- Ran pulsar standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function
- Ran custom E2E test
Thanks,
Philipp
+1 (non-binding)
- Built from source
- Checked the signatures and checksums of the source and binary release
artifacts
- Ran standalone with etcd metastore
- Ran pulsar standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function
Regards,
Yik
+1 (non-binding)
- Built from source
- Checked the signatures and checksums of the source and binary release
artifacts
- Ran pulsar standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function
Regards,
Yike
Fro
I hope to get broader opinions from the community before any such changes are
made.
Especially from Rajan and Enrico. Rajan is the author of
https://github.com/apache/pulsar/pull/9292 and Enrico has approved the PR.
There was a dev mailing list discussion regarding PIP-381 where PR 9292 was
disc
hi,
We should ensure forward and backward compatibility between 3.0 and
4.0. We can enable
configuration(managedLedgerPersistIndividualAckAsLongArray) in 5.0.
Therefore, I believe the default value should be false.
We shouldn't be constrained by the already released 4.0.x versions. I
believe use
15 matches
Mail list logo