Perhaps we can document any known issues in the release notes with an
indication of when they will be patched? That might help users
determine whether to upgrade now or to wait for the next patch
release.
Thanks,
Michael
On Mon, Apr 24, 2023 at 6:06 AM PengHui Li wrote:
>
> Yes, I just want to u
Yes, I just want to understand the process here and try to make it more
clear.
We'd better set a timeline for new feature fixes in the next feature
release.
After the timeline, we only accept fixes for security issues and
regressions.
Thanks,
Penghui
On Mon, Apr 24, 2023 at 6:57 PM Christophe Bo
Yes I agree that we should not ship buggy features.
But also we decided on a time-based release plan so I'd be in favor of
delaying features that are not fully tested to the next release. Hiding
them behind feature flags if needed.
If we do frequent, regular releases, this should not be an issue fo
Il Lun 24 Apr 2023, 12:35 PengHui Li ha scritto:
> Can we cherry-pick fixes for the new features that were introduced to
> 3.0.0?
> We do lots of chaos testing, stress testing for new delayed messages, and
> load balancer
> before the 3.0.0 release. Is it reasonable to have the fixes without
> re
Can we cherry-pick fixes for the new features that were introduced to 3.0.0?
We do lots of chaos testing, stress testing for new delayed messages, and
load balancer
before the 3.0.0 release. Is it reasonable to have the fixes without
releasing buggy
features?
Or the testing should be completed bef
Hi Zike,
I just reverted the commits of PIP-195 (minutes before your mail 😄)
except for
https://github.com/apache/pulsar/commit/e248e14473142765db1df324c20a081a2422980e
Maybe we should keep that one since it will be a breaking change if we
do it later.
Le lun. 24 avr. 2023 à 11:52, Zike Yang a
We can revert it, thanks
Il giorno lun 24 apr 2023 alle 11:52 Zike Yang ha scritto:
> Hi, all
>
> Based on the above discussion, I will revert all these commits. They
> are all related to the improvement of the PIP-195:
> *
> https://github.com/apache/pulsar/commit/e248e14473142765db1df324c20a081
Hi, all
Based on the above discussion, I will revert all these commits. They
are all related to the improvement of the PIP-195:
*
https://github.com/apache/pulsar/commit/e248e14473142765db1df324c20a081a2422980e
*
https://github.com/apache/pulsar/commit/e1d63990644700bf61b3d7af1ef6d4d62145c2bb
*
Hi, Michael
Thanks for your explanation. I'm +1 for keeping these commits.
Thanks,
Zike Yang
On Sat, Apr 22, 2023 at 12:47 AM Michael Marshall wrote:
>
> > So to respect the code freeze, I propose to revert all those commits except:
> > https://github.com/apache/pulsar/pull/19849
> > https://gi
> So to respect the code freeze, I propose to revert all those commits except:
> https://github.com/apache/pulsar/pull/19849
> https://github.com/apache/pulsar/pull/20086
Can you enumerate which commits you want to revert? 19849 was not
cherry picked, so it is not relevant to this discussion.
I f
> I understand that the optimization PRs are nice but if we start to
> accept them, why not accepting all the others and the code freeze
> becomes pointless.
> We can do a 3.0.1 shortly after to include all those enhancements.
Totally +1 for this.
> The mailing list is too "slow" for this kind of
I agree with this, other PRs can move to 3.0.1.
Thanks,
Cong Zhao
On 2023/04/21 09:43:20 Christophe Bornet wrote:
> So to respect the code freeze, I propose to revert all those commits except:
> https://github.com/apache/pulsar/pull/19849
> https://github.com/apache/pulsar/pull/20086
>
> I under
So to respect the code freeze, I propose to revert all those commits except:
https://github.com/apache/pulsar/pull/19849
https://github.com/apache/pulsar/pull/20086
I understand that the optimization PRs are nice but if we start to
accept them, why not accepting all the others and the code freeze
I strongly agree that these cherry-pick should be notified to the release
managers to avoid unintended consequences.
PR https://github.com/apache/pulsar/pull/20086 is to solve a serious bug it
will lead to the pulsar-io block, so it is very necessary to cherry-pick into
3.0. The rest of the PRs
I agree it's documented and the first time can be hard.
But maybe the document is lacking the practical steps for discussing
"Occasional exceptions will be
possible after higher scrutiny of the change" ?
That's why I'm suggesting a clear way for getting in touch with the release
managers
Nicolò B
This process is already documented :
https://pulsar.apache.org/contribute/release-policy/#release-cycles
"For feature releases and LTS releases, the last 3 weeks of the
release cycle will be marked as a code-freeze period. The RM will
branch off from master, and the RM is also responsible for sele
I believe that currently there's no clear process in place in order to
decide whether a commit should be cherry-picked into the frozen branch.
I know that we have a slack channel for the release coordination
#pulsar-release-3_0, which is open to everyone.
One solution would be to let the release m
Hi Zike,
I'm sorry for cherry-picking the new delayed message PRs to branch-3.0.
Would be very grateful if we could get to 3.0 since it is the new feature of
the delayed message and has no impact on other components.
These PR is important to PIP-195, they will fix some problem with the new
d
I cherry picked [0] because it is a very minor change that is required
to make PIP 257 (a PIP introduced in 3.0.0) work for the function
worker deploying functions with alternative authentication data. The
change is covered by a test and only removes a null check that was
creating inconsistent resu
Hi, all
We found that there were a lot of commits that were cherry-picked to
branch-3.0 without any discussion or notification to reach a
consensus. Some PRs marked for the 3.1.0 milestone were also
cherry-picked into branch-3.0. Here are the corresponding
cherry-picked commits:
*
https://github.
20 matches
Mail list logo
