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