I would also agree with the above.
Changing a stable API and deprecating stable methods would need a FLIP in
my opinion. But then executing the removal of previously deprecated methods
would be fine in my understanding.
On Fri, Feb 7, 2020 at 11:17 AM Kurt Young wrote:
> Thanks for the clarifi
Thanks for the clarification, that make sense to me.
Best,
Kurt
On Fri, Feb 7, 2020 at 4:56 PM Timo Walther wrote:
> Hi Kurt,
>
> I agree with Aljoscha. We don't need to introduce a big process or do
> voting but we should ensure that all stakeholders are notified and have
> a chance to raise
Hi Kurt,
I agree with Aljoscha. We don't need to introduce a big process or do
voting but we should ensure that all stakeholders are notified and have
a chance to raise doubts.
Regards,
Timo
On 07.02.20 09:51, Aljoscha Krettek wrote:
I would say a ML discussion or even a Jira issue is enou
I would say a ML discussion or even a Jira issue is enough because
a) the methods are already deprecated
b) the methods are @PublicEvolving, which I don't consider a super
strong guarantee to users (we still shouldn't remove them lightly, but
we can if we have to...)
Best,
Aljoscha
On 07.02.
Hi dev,
Currently I want to remove some already deprecated methods from
TableEnvironment which annotated with @PublicEnvolving. And I also created
a discussion thread [1] to both dev and user mailing lists to gather
feedback on that. But I didn't find any matching rule in Flink bylaw [2] to
follow
