I think before we release 1.0, we need to define and document the compatibility guarantees.
At the moment, the CR changes frequently and as was pointed out earlier, there isn't any automation to ensure changes are backward compatible. In addition, our documentation still refers to upgrade as a process that involves removing the prior CRD, which IMO needs to change for a 1.0 release. If we feel that we are not ready to put a compatibility guarantee in place, then perhaps release the next version as 0.2? Thanks, Thomas [1] https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/operations/upgrade/ On Mon, May 16, 2022 at 5:13 PM Aitozi <gjying1...@gmail.com> wrote: > > Thanks Gyula. It looks good to me. I could do a favor during the release > also. > Please feel free to ping me to help the doc, release and test work :) > > Best, > Aitozi > > Yang Wang <danrtsey...@gmail.com> 于2022年5月16日周一 21:57写道： > > > 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 > > >> > > > >> > > > > >
