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 <t...@apache.org> 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 <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 > > > >> > > > > >> > > > > > > > >
