Hi Gyula, Thanks for the quick response. And your answers to the questions sound good to me.
I'd suggest first creating a "Creating a Flink Kubernetes Operator Release" page and a "Verifying a Flink Kubernetes Operator Release" page on the wiki[1], just like other projects. We can then discuss / comment around the docs and keep refining them. Thank you~ Xintong Song [1] https://cwiki.apache.org/confluence/display/FLINK/Releasing On Mon, Mar 14, 2022 at 4:52 PM Gyula Fóra <gyula.f...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > >
