📖 book: set v1.1.x EOL date

[sbueringer]

Signed-off-by: Stefan Büringer [email protected]

What this PR does / why we need it:
As discussed in the office hours.

I would take care of the next v1.1.x and v1.2.x release in ~ 2 weeks.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

[sbueringer]

/cherry-pick release-1.2

[k8s-infra-cherrypick-robot]

@sbueringer: once the present PR merges, I will cherry-pick it on top of release-1.2 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.2

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[killianmuldoon]

/lgtm

[CecileRobertMichon]

/lgtm

Note that we have this policy in the doc

For each given API version only the most recent associated release branch is supported, older branches are immediately unsupported

We might want to revise it if we're not actually following it in practice

[sbueringer]

/lgtm

Note that we have this policy in the doc

For each given API version only the most recent associated release branch is supported, older branches are immediately unsupported

We might want to revise it if we're not actually following it in practice

Yup. That policy was why I brought it up yesterday in the office hours. With v1.0 and (looks like now too with v1.1) we did one more patch release after the next .0 minor release. This comes roughly down to the previous minor version is supported until one month after the release of the next minor version.

I'm general in favor of revising the policy. Although I wonder if dropping support at the time of the next minor release or one month later is the right thing to do.

Essentially we declared ClusterAPI ready for production, but we are now 1,5 months after the v1.2 release and we don't have releases of the most frequently used infrastructure providers based on and tested with CAPI v1.2. (possibly the current infra provider releases have been tested for compatibility with v1.2, I"m not following infra providers very closely)

That means basically when v1.1 will be out of support in 2 weeks, users can't use a combination of core CAPI and infra providers where both are supported.

[fabriziopandini]

I agree that the implicit feedback from the provider is showing us that we are a little bit too aggressive in setting a release branch EOL even if there are no API changes on the next one.

[fabriziopandini]

/lgtm
/approve

Given that this is compliant with our current deprecation policy.
Let's tackle improvements to the deprecation policy as part of the release team work

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-infra-cherrypick-robot]

@sbueringer: new pull request created: #7186

In response to this:

/cherry-pick release-1.2

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.