Just wanted to point out that when we release 1.0.0 we inevitably also
have to think about what compatibility guarantees we want to give and
how we intend to enforce them.
Additionally it would be good to think about the general approach of
releases; how often are minor/patch releases made, how many versions are
supported, what our plans are for 2.0 (just so we don't end up again in
a situation where we are seemingly unable to release version 2.0).
On 26/04/2022 17:29, Geng Biao wrote:
Thanks for starting the discussion. It is exciting to learn about the plan of
1.0.0 version!
The timeline is fine to me. As for the SQL support, as Yang said, I have got
some basic ideas and try to make a PoC for verification. It may be first
implemented in upstream flink project and then utilized in the k8s operator. I
hope to start a discussion about it soon. And it makes sense to me to leave it
to next major release.
Thanks all guys again for the awesome work.
Best,
Biao Geng
获取 Outlook for iOS<https://aka.ms/o0ukef>
________________________________
发件人: Aitozi <gjying1...@gmail.com>
发送时间: Tuesday, April 26, 2022 10:59:39 PM
收件人: dev@flink.apache.org <dev@flink.apache.org>
主题: Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Thanks Gyula for starting this discussion.
The release time looks good to me. The main code for the session job is
complete,
the doc and other side issues are on the way. I will ping you guys in the
ticket
after the work are completed from my side to help review together whether
there is functionality missing or not (Maybe at the beginning of the May).
Best,
Aitozi.
Yang Wang <danrtsey...@gmail.com> 于2022年4月26日周二 16:07写道：
Thanks Gyula for starting this discussion.
Some users from different companies are also very interested in
flink-kubernetes-operator project and asked me in private when it will be
production ready.
Now I would say the release 1.0.0 aims to this mission.
Given that the SQL support in flink-kubernetes-operator is still under PoC
and users could use tableAPI to work around, I would like to leave it in
the next major version(1.1). cc @Biao Geng
So the release pace, including the feature freeze, the release candidate,
looks really good to me.
I volunteer to help to manage the release 1.0.0 and glad to learn the
knowledge you have obtained.
Best,
Yang
Gyula Fóra <gyf...@apache.org> 于2022年4月26日周二 02:22写道：
Hi Devs!
The community has been working hard on cleaning up the operator logic and
adding some core features that have been missing from the preview release
(session jobs for example). We have also added some significant
improvements around deployment/operations.
With the current pace of the development I think in a few weeks we should
be in a good position to release next version of the operator. This would
also give us the opportunity to add support for the upcoming 1.15 release
:)
We have to decide on 2 main things:
1. Target release date
2. Release version
With the current state of the project I am confident that we could cut a
really good release candidate towards the end of May. I would suggest a
feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
on May 16 we feel that we are ready we could also prepare the release
candidate earlier.
As for the release version, I personally feel that this is a good time
for *version
1.0.0*.
While 1.0.0 signals a certain confidence in the stability of the current
API (compared to the preview release) I would keep the kubernetes
resource
version v1beta1.
It would also be great if someone could volunteer to join me to help
manage
the release process this time so I can share the knowledge gathered
during
the preview release :)
Let me know what you think!
Cheers,
Gyula
