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 >
