community
community copied to clipboard
tektoncd
Guidance for features path from alpha to beta / 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
- Help our features be promoted from alpha to beta / stable
- Give visibility on the status of features and expected promotion timeline
/assign @afrittoli
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopenwith a justification. Mark the issue as fresh with/remove-lifecycle rottenwith a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozenwith a justification./close
Send feedback to tektoncd/plumbing.
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.
We discussed this in the API WG on July 25. The plan is
- [ ] Update our policies/development guide/TEP process to mention that new features start out in the alpha track
- [ ] Update our policies to mention that new feature authors should open an issue to track the feedback on that feature and promotion to beta once the feature lands in a release
- [ ] Consider retroactively opening issues to track feedback/promotion for current features in alpha
- [ ] Implement a quarterly alpha feature review to come up to review current features in alpha (this does not preclude moving features to beta outside of this review. This is mostly a way to ensure all alpha features are reviewed on a regular basis). First one schedule for September 12 during the API WG.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
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 https://github.com/tektoncd/community/issues/515#issuecomment-1195755516 - but I wonder if we should also define the policy so as to encourage features to get to stable.