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