Policy for when to bump versions of Tasks that depend on images in tektoncd/pipeline?

[bobcatfish]

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

[vdemeester]

Whenever there is a change to a Task, we should bump the version. (TEP-0003).

So, in the TEP, the rules around "images" are

New image(s) is(/are) used for the Task

• For images that we own we should only bump the version if the new version breaks CI or if release notes include changes on the Tekton image
• For images that we do not own: it should be the responsibility of the author of the task to verify if changing an image version requires a new Task version
• When the image for a step is specified via an input params, we should treat changes to the default value of that param in the same way as changes to a step image

I did put emphasis on part I feel are important 😛. tektoncd/pipeline are images we own, so, the rules there is "if it breaks the CI or if we know (we == tektoncd/pipeline maintainers) something changed in the image". This means, we don't necessarily need to bump the task version but it's on us (it's our responsability.. if we break users).

/cc @tektoncd/core-maintainers @tektoncd/catalog-maintainers

[chmouel]

Does the binaries from tektoncd/pipeline ensure compatibility between version of pipelines?

[ghost]

Does the binaries from tektoncd/pipeline ensure compatibility between version of pipelines?

Taking git-init as an example, the only intentional breaking change we've introduced (that I can remember) is that we dropped support for short git hashes when we added the refspec field.

Because we use git-init in PipelineResources I think we would hear user reports pretty quickly if a new version of Pipelines broke that image. But I don't think we ensure compatibility in the same strict way we do with Tekton's API surface for example. Just that the primary changes we've introduced to the image are additive rather than changing or taking away from how it works.

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

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]

@tekton-robot: Closing this issue.

In response to this:

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.

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.