Add Instructions for storedVersion Upgrade

[JeromeJu]

Changes

This commit updates the v1 migration guide to add the instructions for the storedVersion upgrade.

/kind documentation
part of #6382

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• [n/a] Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• [n/a] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• [n/a] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

[QuanZhang-William]

Thanks, @JeromeJu!

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: QuanZhang-William
To complete the pull request process, please assign vdemeester after the PR has been reviewed.
You can assign the PR to them by writing /assign @vdemeester in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[JeromeJu]

Thanks for the inputs for #6382 during the pipeline WG.
PTAL for the doc updates for the migration. 🙏
cc @lbernick @pritidesai @vdemeester

[lbernick]

I think we wouldn't want a change in stored version to be transparent to users. It sounded like the docs Vincent mentioned wanting were docs on how to identify whether there are any v1beta1 objects remaining on the cluster, so they can be removed or swapped to v1. Once we have a storage version migrator in place we can also add instructions on how to use that (if any are needed).

[JeromeJu]

I think we wouldn't want a change in stored version to be transparent to users.

Will we want to recommend users to specify v1 CRDs instead of v1beta1 since then? curious because right now the CRD releases only provided with v1 but not yet ask so.

It sounded like the docs Vincent mentioned wanting were docs on how to identify whether there are any v1beta1 objects remaining on the cluster, so they can be removed or swapped to v1

Thanks for clarifications. Sounds like this should be in scope of this PR while we could leave the migrator parts till later when we decide on when we deprecate v1beta1? 🤔

[lbernick]

Yes, I think we should recommend users specify v1 CRDs instead of v1beta1. I think we can accomplish this by having our docs use v1 examples (#6414).

Adding docs for identifying v1beta1 CRDs on the cluster in this PR sounds like a great idea, maybe you and @vdemeester could work together on that?

And yes, we can leave the storage version migrator for later.

[vdemeester]

I am not sure I followed everything, but the storage version switch should be "transparent" for users. They can use v1 or v1beta1 today, and no matter what we use as a storage version this should still remain true.

[JeromeJu]

I think in the previous context, "not transparent" might intend to mean "end users wouldn't be necessary to feel impacted or need to respond to the version upgrade". It makes sense that we shall definitely include in the release note and let users know when we swap:)

[JeromeJu]

Let's close this for now until we are reaching the EOL of v1beta1 :)