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 > > >
