-
Notifications
You must be signed in to change notification settings - Fork 577
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy for when to bump versions of Tasks that depend on images in tektoncd/pipeline? #644
Comments
So, in the TEP, the rules around "images" are
I did put emphasis on part I feel are important 😛. /cc @tektoncd/core-maintainers @tektoncd/catalog-maintainers |
Does the binaries from tektoncd/pipeline ensure compatibility between version of pipelines? |
Taking Because we use |
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. |
Expected Behavior
Whenever there is a change to a Task, we should bump the version. (TEP-0003).
We should decide if we want to follow this strategy for Catalog items that depend on images published in tektoncd/pipeline (these images)and be consistent about it.
Actual Behavior
We sometimes bump the version of the image being used b/c we've made an update but we rarely bump the version of the Task itself. (e.g. #597)
Steps to Reproduce the Problem
Example:
Additional Info
More discussion in tektoncd/pipeline#3258
The text was updated successfully, but these errors were encountered: