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