Hi Xintong! Thank you for the valuable input, you are completely right we need to agree and document these aspects.
Let me try to address some of the questions and others should chip in also :) 1. Version convention: I think we should adopt the 3 digit versioning scheme like other flink projects (I think flink-shaded is a bit of an outlier here). The preview release should be 0.1.0. The supported Flink versions should be documented with the release, each version of the operator should technically be able to support multiple Flink versions at the same time. For the preview release this should be Flink version >= 1.14. We should later come up with a guarantee that we do not drop flink version support within the same minor version. The only public API here at the moment are the custom resource definitions. We agreed to mark them all experimental for the preview release, and I think for 1.0.0 we should aim for public evolving. Otherwise we should respect the Flink guarantees here. Practically this means that for the preview release we do not guarantee anything in terms of later compatibility. 2. Release process: I agree that we should follow the official Flink process as much as possible (and makes sense) with proper voting etc. Cheers, Gyula On Mon, Mar 14, 2022 at 8:32 AM Xintong Song <tonysong...@gmail.com> wrote: > How everyone, > > It's great to learn that we are approaching a preview release for > the flink-kubernetes-operator. Thanks for the efforts. > > I have not been involved with any developing efforts in > flink-kubernetes-operator, thus have no comment on end of March being the > targeting date. > > However, based on my experiences being one of the Flink release managers, I > see a few things that are still missing for creating an official release. > (IIUC, the preview release is still an official release, just with weak > functionality and compatibility guarantees.) > > 1. The version conventions: > - How does a flink-kubernetes-operator version look like? E.g., flink / > flink-statefun / flink-ml have three digits x.y.z, while flink-shaded has > only two digits x.y. > - What is the relationship between flink-kubernetes-operator and flink > versions? E.g., flink-shaded x.* is only designed to support flink *.x.*. > - What kind of compatibility guarantees do we provide? E.g., flink expects > no Public API compatibility should be broken between minor releases (the > 2nd digit) and no PublicEvolving APIs should be broken between bugfix > releases (the 3rd digit). > - What kind of support do we provide for old releases? E.g., flink provides > bug fixes for the latest two minor releases (the 2nd digit). > > 2. Release process > You may find the release process for all Flink artifacts in this wiki page > [1]. Such a formal documented process would help us to reach consensus on > what needs to be done and make sure it complies with the ASF regulations > before creating a release. We probably don't need something as formal as a > vote to approve the release process. But we definitely need a formal vote > for the flink-kubernetes-operator release, and the release process would > help making sure we are on the same page about what is a releasable state > for this artifact. > > WDYT? > > Thank you~ > > Xintong Song > > > [1] https://cwiki.apache.org/confluence/display/FLINK/Releasing > > On Mon, Mar 14, 2022 at 11:34 AM Biao Geng <biaoge...@gmail.com> wrote: > > > Hi there, > > > > It is exciting to see the discussion of the release timeline! I agree > that > > the end of March is a proper date. > > To make others easier get involved in this discussion, I think we may > need > > to provide a more straightforward feature list for the preview release. > The > > "Initial Feature Set" in FLIP-212 > > < > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-212:+Introduce+Flink+Kubernetes+Operator > > > > > is > > almost complete. But some new features like webhook based validate and > > flink operator metric are not added and they are only tracked in the long > > JIRA list. If we can update the FLIP, it may be more convenient and can > > also help us write release notes later. I also created a draft > > < > > > https://github.com/bgeng777/flink-kubernetes-operator/blob/features/doc/features.md > > > > > for myself to track completed or in-plan features. Hope it can help. > > > > Best, > > Biao Geng > > > > Gyula Fóra <gyula.f...@gmail.com> 于2022年3月14日周一 04:11写道： > > > > > @Konstantin: Yes I completely agree that for this release the API (CRD) > > > should be marked experimental! > > > I have opened a ticket to track this: > > > https://issues.apache.org/jira/browse/FLINK-26620 > > > > > > @Yang Wang <danrtsey...@gmail.com> : I think we still have plenty of > > time > > > to work on features like the session job before the release, would be > > nice > > > to provide a complete story to the users. > > > > > > Gyula > > > > > > On Sun, Mar 13, 2022 at 5:17 PM Konstantin Knauf <kna...@apache.org> > > > wrote: > > > > > > > Hi everyone, > > > > > > > > can we mark all the APIs as experimental/alpha so that it is clear > that > > > > these can be broken in future releases for now? I think this would be > > > very > > > > important given the early stage of the project. We want to be able to > > > > address shortcomings without worrying too much about backwards > > > > compatibility at this stage, I believe. > > > > > > > > Cheers, > > > > > > > > Konstantin > > > > > > > > On Sun, Mar 13, 2022 at 7:48 AM Yang Wang <danrtsey...@gmail.com> > > wrote: > > > > > > > > > Thanks Gyula for starting this discussion. > > > > > > > > > > Given that the core functionality is closing to stable, I am in > favor > > > of > > > > > having the MVP release at the end of March. > > > > > The first release will help us to collect more feedbacks from the > > > users. > > > > > Also it is a good chance to let the users know that the community > is > > > > trying > > > > > to maintain an official Kubernetes operator :) > > > > > I hope that the companies could build their own production > streaming > > > > > platform on top of the flink-kubernetes-operator in the future. > > > > > > > > > > FYI: @Wenjun Min is still working hard on supporting the Session > Job > > in > > > > > Flink Kubernetes operator, It will be great if we could include it > in > > > the > > > > > first release. > > > > > And I believe we have enough time. > > > > > > > > > > Moreover, I agree with you that we need to invest more time in the > > > > > documentation, e2e tests, helm install optimization, logging, > > > > > etc. before the release. > > > > > > > > > > > > > > > Best, > > > > > Yang > > > > > > > > > > > > > > > Gyula Fóra <gyf...@apache.org> 于2022年3月12日周六 01:10写道： > > > > > > > > > > > Hi Team! > > > > > > > > > > > > I would like to discuss the timeline for the initial > > > preview/milestone > > > > > > release of the flink-kubernetes-operator > > > > > > <https://github.com/apache/flink-kubernetes-operator> project. > > > > > > > > > > > > The last few weeks we have been working very hard with the > > community > > > to > > > > > > stabilize the initial feature set and I think we have made great > > > > > progress. > > > > > > While we are still far from a production ready-state, a preview > > > release > > > > > > will give us the opportunity to reach more people and gather much > > > > needed > > > > > > input to take this project to the next level. > > > > > > > > > > > > There are still a couple missing features that we need to iron > out > > > and > > > > we > > > > > > need to make sure we have proper documentation but after that I > > think > > > > it > > > > > > would be a good time for the preview release. > > > > > > > > > > > > I propose to aim for the first release candidate around the > 25-27th > > > of > > > > > > March after which we should dedicate a few days for some > extensive > > > > > testing > > > > > > and bugfixing. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > Gyula > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Konstantin Knauf > > > > > > > > https://twitter.com/snntrable > > > > > > > > https://github.com/knaufk > > > > > > > > > >
