Hi @ruiwen-zhao. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/ok-to-test

@ruiwen-zhao: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

/ok-to-test

(I don't know why you still need this?)

also note adding noise in the LTS for people/clouds that don't want to move up/change their crictl/kubelet version...well think it over..

We had a discussion about that on #9315 (comment). Where we ended up is: users may upgrade directly from 1.6 (an LTS) to 2.0 or the next LTS, skipping 1.7. Omitting known deprecations from 1.6 (even if the feature isn't deprecated in 1.6) means these users might miss the warning and be surprised at upgrade.

fair

The warnings are a simple ID + message + timestamp right now. We could also add something like a "first-deprecated-in" output, and users running a 1.6 release but seeing a 1.7 version there could know that it's not actually deprecated in 1.6, but that they should take care when upgrading anyway. But I haven't convinced myself of that approach yet.

I suppose this is one reason some projects require upgrades be sequential

This is the doc I had put together on the design approach I was taking. If you look in the "Bikeshedding" section there's some discussion on the warning contents, but I hadn't gotten much feedback on it yet.

should be noted that even on 1.6 v1 cri is the default