Update policy to bump Task/Pipeline versions whenever a change is made

[bobcatfish]

Expected Behavior

As a user of Tasks in the catalog, when I use Task (or Pipeline) and I specify a specific version X, I should be confident that the Task (or Pipeline) I use at time Y is the same as the version at time Y+1, etc.

That is: if anything that is user facing in a Task (or Pipeline) changes, the version of should be bumped.

Actual Behavior

We make changes to Tasks without bumping the version, for example:

• https://github.com/tektoncd/catalog/pull/763: Adds a new variable to git-clone 0.1 (not 0.2 or 0.3, not sure why not), and changes the default value of that variable for 0.4
• https://github.com/tektoncd/catalog/pull/711: Converts params to env vars before using them

Anyone grabbing the git-clone 0.1 or 0.4 Task BEFORE these changes would get something different AFTER these changes (and which version will be available in our OCI registry? I'm assuming the latest one, but not sure?)

My understanding of why these changes being made without bumping the version is b/c we view these as additive; however:

1. without knowing exactly how users are using the Tasks/Pipelines, we can't know if these changes will break them (see steps to reproduce)
2. with everything else we version (e.g. releases of Tekton Pipelines), we create a new version even if the changes are additive, or even in the case of bug fixes: we don't update v0.14.0 to contain a fix, we make a new release, v0.14.1, so that we can clearly communicate to our users that there has been a change

Steps to Reproduce the Problem

I want to demonstrate an example of how this can impact a user by describing how this impacted me recently.

I've been working on a custom task that runs a Pipeline as a TaskRun (https://github.com/tektoncd/experimental/pull/770) and I created an example Pipeline which used git-clone 0.3.

1. I installed git-clone with tkn hub install task git-clone (i didnt explicitly specify the version i needed but let's pretend i said 0.3 which is what i ended up working with)
2. I created a Pipeline that used git-clone and used it to experiment
3. I decided to create an end to end test that used the same git-clone - I wrote the TaskRun I expected (with the git-clone steps, params, etc. embedded in it) based on the git-clone task i had installed
4. The last part of my test setup was to grab the git-clone 0.3 yaml from the catalog repo and add it to a testdata folder
5. My tests failed! because the Task had changed since I grabbed it (the params -> env var change), my resulting TaskRun was now different

• git-clone 0.3 which I was initially working with
• git-clone 0.3 which I'd get I tried to pull 0.3 now

Additional Info

• https://github.com/tektoncd/catalog/issues/644 is a similar issue but I'd opened this in the context of changes to images specifically, so I'd like to open this again to discuss any changes to Tasks (and Pipelines)

I'm wondering if one reason we're doing this is we've made it too expensive to bump a version - bumping a version means creating a whole new directory of READMEs, yamls, examples, etc. (not to mention it's hard to tell what's changed b/w versions).

If that's the case, it might be worth revisiting our approach. OR we could try something different, now that we're publishing to an OCI registry, like deleting the old version when we make a change.

[jerop]

/assign

[vdemeester]

If that's the case, it might be worth revisiting our approach. OR we could try something different, now that we're publishing to an OCI registry, like deleting the old version when we make a change.

OCI bundle are not stable yet, so we can assume most of our user do not use them / have access to them. We can't rely on them completely until it's available for everyone.

[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.

[jerop]

/lifecycle frozen

we need to establish this policy and make it easy to make bumps - @vinamra28 and I are discussing this

draft: https://docs.google.com/document/d/1SGOkVrg0_s8ufbSTRl0Y4l_2zD_0QgUElEDZY0p8jSk/edit?usp=sharing

[jerop]

/lifecycle frozen

[jerop]

initial work addressing this is here: https://github.com/tektoncd/community/blob/main/teps/0110-decouple-catalog-organization-and-reference.md