-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Guidance for features path from alpha to beta / stable #515
Comments
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
/cc @dibyom |
/remove-lifecycle rotten |
/assign |
We discussed this in the API WG on July 25. The plan is
|
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
/remove-lifecycle rotten |
/lifecycle frozen |
This is what k8s does (or used to do in 2020): https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/. I think that would work if we received a ton of feedback on features, but often that's not the case. We should implement at least the points mentioned in #515 (comment) - but I wonder if we should also define the policy so as to encourage features to get to stable. |
Feature request
TEPs allow us to design new features to be added to Tekton.
Those features will usually be introduced as alpha.
We should have general guidance for features to progress from alpha to beta and stable in terms of requirements and timeline.
We could have a section in the TEP for authors to think about any special requirement or timeline for their feature to be promoted to beta / stable.
We could use this information to document the ETA release for a feature to become beta / stable.
Use case
/assign @afrittoli
The text was updated successfully, but these errors were encountered: