[DISCUSS] Flink Kubernetes Operator release cadence proposal

[Őrhidi Mátyás <ma...@gmail.com>]

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

Re: [DISCUSS] Flink Kubernetes Operator release cadence proposal

[Őrhidi Mátyás <ma...@gmail.com>]

Hi Devs,

I've created the wiki page Release Schedule and Planning
<https://cwiki.apache.org/confluence/display/FLINK/Release+Schedule+and+Planning>
for
the Operator. Let's keep it up-to-date :)

Thank you all for your valuable inputs!

Cheers,
Matyas

On Mon, Jun 27, 2022 at 10:14 AM Őrhidi Mátyás <ma...@gmail.com>
wrote:

> Thanks, Gyula, working on it. Will update the thread today.
>
> Thanks,
> Matyas
>
> On Mon, Jun 27, 2022 at 9:10 AM Gyula Fóra <gy...@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 <ba...@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 <da...@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 <gy...@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.orhidi@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
>>> > > >
>>> > >
>>> >
>>>
>>

Re: [DISCUSS] Flink Kubernetes Operator release cadence proposal

[Őrhidi Mátyás <ma...@gmail.com>]

Thanks, Gyula, working on it. Will update the thread today.

Thanks,
Matyas

On Mon, Jun 27, 2022 at 9:10 AM Gyula Fóra <gy...@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 <ba...@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 <da...@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 <gy...@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.orhidi@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
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] Flink Kubernetes Operator release cadence proposal

[Gyula Fóra <gy...@gmail.com>]

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 <ba...@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 <da...@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 <gy...@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.orhidi@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
> > > >
> > >
> >
>

Re: [DISCUSS] Flink Kubernetes Operator release cadence proposal

[Márton Balassi <ba...@gmail.com>]

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 <da...@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 <gy...@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 <ma...@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
> > >
> >
>

Re: [DISCUSS] Flink Kubernetes Operator release cadence proposal

[Yang Wang <da...@gmail.com>]

+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 <gy...@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 <ma...@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
> >
>

Re: [DISCUSS] Flink Kubernetes Operator release cadence proposal

[Gyula Fóra <gy...@gmail.com>]

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 <ma...@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
>