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 >
