Thanks Gyula for sharing the progress. It is very likely we could have the first release candidate next Monday.
Best, Yang Gyula Fóra <gyf...@apache.org> 于2022年5月16日周一 20:50写道： > Hi Devs! > > We are on track for our planned 1.0.0 release timeline. There are no > outstanding blocker issues on JIRA for the release. > > There are 3 outstanding new feature PRs. They are all in pretty good shape > and should be merged within a day: > https://github.com/apache/flink-kubernetes-operator/pull/213 > https://github.com/apache/flink-kubernetes-operator/pull/216 > https://github.com/apache/flink-kubernetes-operator/pull/217 > > As we agreed previously we should not merge any more new features for > 1.0.0 and focus our efforts on testing, bug fixes and documentation for > this week. > > I will cut the release branch tomorrow once these PRs are merged. And the > target day for the first release candidate is next Monday. > > The release managers for this release will be Yang Wang and myself. > > Cheers, > Gyula > > On Wed, Apr 27, 2022 at 11:28 AM Yang Wang <danrtsey...@gmail.com> wrote: > >> Thanks @Chesnay Schepler <ches...@apache.org> for pointing out this. >> >> The only public interface the flink-kubernetes-operator provides is the >> CRD[1]. We are trying to stabilize the CRD from v1beta1. >> If more fields are introduced to support new features(e.g. standalone >> mode, >> SQL jobs), they should have the default value to ensure compatibility. >> Currently, we do not have some tools to enforce the compatibility >> guarantees. But we have created a ticket[1] to follow this and hope it >> could be resolved before releasing 1.0.0. >> >> Just as you said, now is also a good time to think more about the approach >> of releases. Since flink-kubernetes-operator is much simpler than Flink, >> we >> could have a shorter release cycle. >> Two month for a major release(1.0, 1.1, etc.) is reasonable to me. And >> this >> could be shorten for the minor releases. Also we need to support at least >> the last two major versions. >> >> Maybe the standalone mode support is a big enough feature for version 2.0. >> >> >> [1]. >> >> https://github.com/apache/flink-kubernetes-operator/tree/main/helm/flink-kubernetes-operator/crds >> [2]. https://issues.apache.org/jira/browse/FLINK-26955 >> >> >> @Hao t Chang <htch...@us.ibm.com> We do not have regular sync up meeting >> so >> far. But I think we could schedule some sync up for the 1.0.0 release if >> necessary. Anyone who is interested are welcome. >> >> >> Best, >> Yang >> >> >> >> >> Hao t Chang <htch...@us.ibm.com> 于2022年4月27日周三 07:45写道： >> >> > Hi Gyula, >> > >> > Thanks for the release timeline information. I would like to learn the >> > gathered knowledge and volunteer as well. Will there be sync up >> > meeting/call for this collaboration ? >> > >> > From: Gyula Fóra <gyf...@apache.org> >> > Date: Monday, April 25, 2022 at 11:22 AM >> > To: dev <dev@flink.apache.org> >> > Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline >> > 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 >> > >> >
