Bump knative/pkg to release-1.6

[vdemeester]

Changes

This also updates it in ./hack/update-deps.sh to be inline with what
we fetch (before this PR, the VERSION there is not the one we depend
on / vendor).

Signed-off-by: Vincent Demeester [email protected]

/kind misc

This will bring up the minimum version for Kubernetes to 1.22, so we will need to bump the version of k8s we provision with boskos.

/cc @imjasonh @afrittoli @jerop @abayer

Submitter Checklist

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

• Docs included if any changes are user facing
• Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Release notes block below has been filled in
  (if there are no user facing changes, use release note "NONE")

Release Notes

Bump knative/pkg dependency to 1.15.
action required: this will bring up the minimum version for Kubernetes to 1.22

[vdemeester]

/cc @imjasonh @mattmoor

[vdemeester]

/retest

[abayer]

Once we get boskos provisioning 1.22 and the various other clusters upgraded, this should be fine. =)

[vdemeester]

Once we get boskos provisioning 1.22 and the various other clusters upgraded, this should be fine. =)

I need to find out how we bump the version boskos provides.. 😅

[vdemeester]

arg… wrong button 🤦🏼

[vdemeester]

/retest

[vdemeester]

@abayer @pritidesai @afrittoli Should we wait for 0.38 to be released to bump this ?
(imo, I think so)

[imjasonh]

Should update this to @main again, and fix changeset.Get calls accordingly. This will require us to build with Go 1.18+

[vdemeester]

but then, what should be the value for https://github.com/tektoncd/pipeline/pull/4928/files#diff-ff3402c713d8a504795b7115caa1af088b1bfc583d43adb5d0bc5a83aaa03bc1L25 ?

[imjasonh]

Sorry you're right, good point. We should wait for the next knative release that includes the changeset.Get changes, and bump to use that.

[imjasonh]

This could also be two changes: one to bump to 1.5, and a future one (which I can do if you want) to bump to 1.6 and include changeset.Get goodness.

[vdemeester]

Yep, I am fine with both, depends on when this one gets merged 😝

[imjasonh]

FWIW knative/pkg release-1.6 is out: https://github.com/knative/pkg/tree/release-1.6

1.7 should include the changeset changes.

[vdemeester]

Yay I will update to 1.6 then 😇

[abayer]

We're still waiting for 0.38.0, fwiw. =)

[vdemeester]

We're still waiting for 0.38.0, fwiw. =)

didn't we already decide which commit to use for 0.38.0 (and even created a release branch from it) ? 😅

[vdemeester]

/retest

[abayer]

/lgtm

[vdemeester]

/cc @afrittoli @lbernick

[lbernick]

I don't have much context here:

• what was the reason to wait until 0.38?
• have concerns about bumping the min k8s version been resolved?
• do we need knative 1.7 to pick up the changeset changes Jason mentioned or is 1.6 sufficient?

[vdemeester]

• what was the reason to wait until 0.38?

Bumping min kubernetes version was the reason to wait for 0.38 👼🏼

• have concerns about bumping the min k8s version been resolved?

Yes, the CI is green now 😛

• do we need knative 1.7 to pick up the changeset changes Jason mentioned or is 1.6 sufficient?

Nope, 1.6 is sufficient 👼🏼

[lbernick]

Do we have any developer docs on bumping our min k8s version? It seems backwards incompatible even if it's not exactly part of the api so just wondering if we have any policies around this.

[afrittoli]

Do we have any developer docs on bumping our min k8s version? It seems backwards incompatible even if it's not exactly part of the api so just wondering if we have any policies around this.

It's part of the release notes and of the top level README.
We should have a more formal statement about k8s min version changes.
Let's check with the knative team if there is a policy on their side that we can piggy back on.

Table of k8s version: https://github.com/tektoncd/pipeline#required-kubernetes-version
We currently document min version only, once we have k8s matrix test in place we could document max version (as long as we test older branches for that).

It would be good to have a process to trace k8s deprecations.

[abayer]

cc @tektoncd/core-maintainers - does anyone object to merging this?

EDIT: And if not, could someone approve? =)

[lbernick]

@XinruZhang opened #5300 to discuss our general process for k8s bumps (thanks Xinru!) and I don't think there are any immediately relevant concerns for this one specifically.

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lbernick

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lbernick]

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