The whole release plan sounds good to me. Thanks for driving this. Best, Yang
Gyula Fóra <gyf...@apache.org> 于2022年3月23日周三 16:22写道： > Hi Team! > > I think we are in good shape to cut the preview release branch in a few > days and start testing. > I suggest we aim for a feature freeze on Friday the 25th (except for the > ongoing session job work which might need 1-2 extra days) and cut the > release branch on Monday the 28th (and hopefully prepare the first RC). > > Until then we should work out the missing pieces around publishing the > artifacts and aim to wrap up any critical outstanding tickets. > > Cheers! > Gyula > > On Tue, Mar 15, 2022 at 3:48 AM Aitozi <gjying1...@gmail.com> wrote: > > > Hi all > > Thanks for starting the discussion. The first release at the end of > > March looks good to me, I think the flink-kubernetes-operator is in a > good > > shape now. I will try to complete the design to support the session job > in > > these two days and will start another discussion before the work. > > Regarding what has to be improved before release, I think the > operator > > metrics are not completed yet, we may have to inject more useful metrics. > > The feature list > > > https://github.com/bgeng777/flink-kubernetes-operator/blob/features/doc/features.md > posted > > by @Biao Geng looks good, Maybe we could include this to track the > > supported features. > > > > Best, > > Aitozi. > > > > Gyula Fóra <gyula.f...@gmail.com> 于2022年3月14日周一 16:58写道： > > > >> 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 > >> > > > > > >> > > > > >> > > > >> > > >> > > >
