[RFC] Increase support window for v1beta1 CRDs to 1 year

[lbernick]

This commit updates the support policy for v1beta1 CRDs to 1 year, to give users more time to migrate off of the v1beta1 API.

v1beta1 is considered a special case because there were no stable APIs available when it was created. To avoid users becoming dependent on future unstable APIs and inhibiting development, the existing policy of 9 months will apply to future beta CRDs.

/kind documentation

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
• n/a Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
• n/a Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

Support window for beta CRDs increased to 1 year

[afrittoli]

Thank you @lbernick

I thought about this a bit more, and I wonder if perhaps we should leave the current policy for changes to a beta API as it is, and add an extra clause specific about the full removal of an API?

I think 9 months is quite a long time already and I'm afraid that if we make it even longer it will inhibit development when we get to a v2alpha1 release, because switching to v2beta1 would already mean 1 year stability commitment, which would result again in us stagnating on the unstable API versions, customers adopting them even if they are unstable, and then the cycle repeating.

Perhaps instead we could leave the 9 months as they are, and possibly reduce them in future, and add a clause specific for v1beta1 removal.

[vdemeester]

Thank you @lbernick

I thought about this a bit more, and I wonder if perhaps we should leave the current policy for changes to a beta API as it is, and add an extra clause specific about the full removal of an API?

I think 9 months is quite a long time already and I'm afraid that if we make it even longer it will inhibit development when we get to a v2alpha1 release, because switching to v2beta1 would already mean 1 year stability commitment, which would result again in us stagnating on the unstable API versions, customers adopting them even if they are unstable, and then the cycle repeating.

Perhaps instead we could leave the 9 months as they are, and possibly reduce them in future, and add a clause specific for v1beta1 removal.

That would work for me too (aka both approach LGTM 🙃 )

[lbernick]

@afrittoli just to make sure I understand what you're suggesting:

• changes to beta api can be done w/ 9 month warning
• changes to beta features can be done w/ 9 month warning
• a beta crd can't be fully removed until 1 year after it's deprecated?

Or are you suggesting the v1beta1 api is a special case?

FWIW I share your concerns about increasing the support window and having users come to rely on beta apis.

[lbernick]

@afrittoli @vdemeester I've updated the proposal to apply to v1beta1 only based on your feedback, PTAL!
@tektoncd/core-maintainers please weigh in by the end of the week; I will merge this PR then if it has approval/lgtm and no pushback.

[afrittoli]

Thanks for the update @lbernick !

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afrittoli, vdemeester

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 [afrittoli,vdemeester]

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

[afrittoli]

/test pull-tekton-pipeline-go-coverage-df

[tekton-robot]

@afrittoli: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

• /test pull-tekton-pipeline-alpha-integration-tests
• /test pull-tekton-pipeline-beta-integration-tests
• /test pull-tekton-pipeline-build-tests
• /test pull-tekton-pipeline-integration-tests
• /test tekton-pipeline-unit-tests

The following commands are available to trigger optional jobs:

• /test pull-tekton-pipeline-go-coverage

Use /test all to run all jobs.

In response to this:

/test pull-tekton-pipeline-go-coverage-df

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.

[afrittoli]

/hold just waiting until the end of the day

[afrittoli]

/lgtm

[lbernick]

/hold cancel