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 >> > > > >> > > >> > >> >
