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