Hi Devs, I've created the wiki page Release Schedule and Planning <https://cwiki.apache.org/confluence/display/FLINK/Release+Schedule+and+Planning> for the Operator. Let's keep it up-to-date :)
Thank you all for your valuable inputs! Cheers, Matyas On Mon, Jun 27, 2022 at 10:14 AM Őrhidi Mátyás <matyas.orh...@gmail.com> wrote: > Thanks, Gyula, working on it. Will update the thread today. > > Thanks, > Matyas > > On Mon, Jun 27, 2022 at 9:10 AM Gyula Fóra <gyula.f...@gmail.com> wrote: > >> Matyas, I think we have an agreement here :) >> >> It would be nice if you could add a release plan page to the wiki for the >> operator to formalize this. Then at the beginning of each release cycle we >> could agree on larger features to be included in the upcoming release. >> For now the only large work-in-progress feature is the standalone >> integration. I think we can reasonably expect that only for 1.2.0. >> >> Gyula >> >> >> >> >> On Wed, Jun 22, 2022 at 10:54 AM Márton Balassi <balassi.mar...@gmail.com> >> wrote: >> >>> Thanks for the proposal, Matyas. >>> >>> +1 for 2 month release cycles with the breakdown Gyula suggested. >>> >>> @Yang: we could start tagging features with 1.1 / 1.2 version then, good >>> call. >>> >>> On Wed, Jun 22, 2022 at 4:58 AM Yang Wang <danrtsey...@gmail.com> wrote: >>> >>> > +1 for 2 month release cycles. >>> > >>> > Since we have promised the backward compatibility for CRD, I think it >>> is >>> > also reasonable for us to maintain the latest two minor versions with >>> patch >>> > releases. >>> > >>> > Given that we only have 5~6 weeks for feature development, maybe we >>> need to >>> > confirm down the features as soon as possible in the release cycle. >>> > Otherwise, we are at great risk of delay. If we are targeting the 1.1.0 >>> > release to Aug 1. It is the time to determine which features we want to >>> > include in this release. >>> > >>> > I agree with Gyula that we need to continuously improve the test >>> coverage, >>> > especially the e2e tests. The users are very welcome to share their >>> > production use cases >>> > and we could consider whether they could be covered by e2e tests. >>> Benefit >>> > from this, we could ship a stable release more quickly and easily. >>> > >>> > >>> > >>> > Best, >>> > Yang >>> > >>> > Gyula Fóra <gyula.f...@gmail.com> 于2022年6月21日周二 19:57写道： >>> > >>> > > Hi Matyas! >>> > > >>> > > Thanks for starting the discussion. I think the 2 month release cycle >>> > > sounds reasonable. >>> > > >>> > > I think it's important for users to have frequent operator releases >>> as >>> > > these affect all Flink jobs running in the environment. We should >>> also >>> > only >>> > > adopt a schedule that we can most likely keep. >>> > > If we want to be successful with the proposed schedule we have to >>> ensure >>> > > that each release has a relatively small scope of new features and we >>> > have >>> > > good test coverage. >>> > > >>> > > In addition to your suggestion I would like to add a feature-freeze >>> for >>> > > bigger new features after 5 weeks (1 week before cutting the release >>> > > branch). >>> > > >>> > > So in practice for 1.1.0 this would look like: >>> > > >>> > > - Jun 6 : 1.0.0 was released >>> > > - July 11: Feature Freeze >>> > > - July 18: Cut release-1.1 branch >>> > > - Aug 1: Target 1.1.0 release date >>> > > >>> > > Cheers, >>> > > Gyula >>> > > >>> > > On Tue, Jun 21, 2022 at 9:04 AM Őrhidi Mátyás < >>> matyas.orh...@gmail.com> >>> > > wrote: >>> > > >>> > > > Hi Devs, >>> > > > >>> > > > After the successful Kubernetes Operator 1.0.0 release, which is >>> > > > considered to be the first production grade one, it is probably a >>> good >>> > > time >>> > > > now to also agree on a predictable release cadence for the Operator >>> > too, >>> > > > similarly to the time-based release plan we have for the Flink core >>> > > project. >>> > > > >>> > > > Given that the Operator itself is not strictly bound to Flink >>> versions >>> > it >>> > > > can be upgraded independently from the runtime versions it >>> manages. It >>> > > > would benefit the community to have frequent minor releases until >>> the >>> > > > majority of the roadmap items are complete that also encourages >>> users >>> > to >>> > > > upgrade regularly in reasonable boundaries. Based on some offline >>> > > > discussion with Gyula Fora I would like to propose the following >>> > > > operational model for Operator releases: >>> > > > >>> > > > - time-based release cadence with 2 month release cycles ( This >>> would >>> > > give >>> > > > us roughly 6 weeks pure dev time and leave 2 weeks for the release >>> > > process >>> > > > to finish) >>> > > > - on-demand patch releases for critical issues only >>> > > > - support the current and previous minor releases with bug fixes >>> > > > >>> > > > I am looking forward to your feedback and suggestions on this >>> topic. >>> > Once >>> > > > we have an agreement I will formalize it on a Wiki page. >>> > > > >>> > > > Thanks, >>> > > > Matyas >>> > > > >>> > > >>> > >>> >>
