Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Hi Thomas! Thank you for raising your concerns. I agree that we should document the compatibility guarantees that we expect to provide going forward. Since releasing 0.1 (v1alpha1) we added a great deal of new core features. This required some modification to the CR obviously but actually it only touched the status subresource and the mainly user facing spec itself had only backward compatible changes. In the future we also would like to start moving fields out from the status to some configmaps to make it easier to change logic in the future (this can be done in a backward compatible way). Based on these I think it is fair to say that we expect to keep backward compatibility going forward for the CR itself and I think release version 1.0.0 (with api version v1beta1) shows our confidence in the overall spec and design. With the core features covered I would consider this production ready and 1.0.0 marks it so, based on the wider experience we gain from users we will can further improve the design towards the v1 api release (in a backward compatible way :)) As for the upgrade docs you linked, it explains the process of upgrading from the currently experimental v1alpha1 to the new v1beta1 release. For this release this is the relevant process, but certainly we need to upgrade before the next release. Also you are right that the automation is not there, that again is definitely a blocker for the next release to ensure backward compatibility. We have tickets already for these 2 tasks. [1][2] Cheers Gyula [1] https://issues.apache.org/jira/browse/FLINK-26955 [2] https://issues.apache.org/jira/browse/FLINK-27302 On Thu, May 19, 2022 at 2:26 AM Thomas Weise wrote: > 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 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 于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 于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 > > > wrote: > > > > > > > >> Thanks @Chesnay Schepler 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. > > > >> > > > >> May
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
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 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 于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 于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 > > wrote: > > > > > >> Thanks @Chesnay Schepler 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 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 于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 > > >> > Date: Monday, April 25, 2022 at 11:22 AM > > >> > To: dev > > >> > 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 rel
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
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 于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 于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 > wrote: > > > >> Thanks @Chesnay Schepler 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 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 于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 > >> > Date: Monday, April 25, 2022 at 11:22 AM > >> > To: dev > >> > 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 > >> > > >> > > >
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Thanks Gyula for sharing the progress. It is very likely we could have the first release candidate next Monday. Best, Yang Gyula Fóra 于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 wrote: > >> Thanks @Chesnay Schepler 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 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 于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 >> > Date: Monday, April 25, 2022 at 11:22 AM >> > To: dev >> > 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 >> > >> >
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
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 wrote: > Thanks @Chesnay Schepler 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 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 于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 > > Date: Monday, April 25, 2022 at 11:22 AM > > To: dev > > 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 > > >
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Thanks @Chesnay Schepler 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 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 于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 > Date: Monday, April 25, 2022 at 11:22 AM > To: dev > 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 >
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
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 Date: Monday, April 25, 2022 at 11:22 AM To: dev 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
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Just wanted to point out that when we release 1.0.0 we inevitably also have to think about what compatibility guarantees we want to give and how we intend to enforce them. Additionally it would be good to think about the general approach of releases; how often are minor/patch releases made, how many versions are supported, what our plans are for 2.0 (just so we don't end up again in a situation where we are seemingly unable to release version 2.0). On 26/04/2022 17:29, Geng Biao wrote: 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 发送时间: Tuesday, April 26, 2022 10:59:39 PM 收件人: [email protected] 主题: 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 于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 于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
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
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 发送时间: Tuesday, April 26, 2022 10:59:39 PM 收件人: [email protected] 主题: 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 于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 于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 > > >
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 于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 于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 > > >
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
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 于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 >
