Build succeeded.

• containerd-build-arm64 : FAILURE in 1m 57s (non-voting)

1.4 is now in Extended support (since November 3, 2021), so unless there's a strong need to backport this we should probably not.

1.4 is now in Extended support (since November 3, 2021), so unless there's a strong need to backport this we should probably not.

@samuelkarp I strongly suggest backport. We will not upgrade to 1.5 soon. And a lot of user still use 1.4.

I strongly suggest backport. We will not upgrade to 1.5 soon. And a lot of user still use 1.4.

Firstly, we also recommend backporting this into your internal 1.4 branches along with any other fixes for bugs you are experiencing on that branch.

Let me try to explain our reasoning here and see if this change would apply since whether it is necessary in the branch is subjective. We added the extended support to mean we consider the branch to be stable and will only be doing releases for security issues or high impact stability issues. The attitude of "we will not upgrade to 1.5 soon" applies to many who prefer to be on the most stable version of software. By putting changes onto this branch, any release for a security or serious issue will also include this change. The feedback we have gotten from these more conservative users is that they would prefer to keep these releases smaller in scope because they are seen as must update releases, while also they are perfectly fine carrying the other patches they deem most important to them. We realize we cannot nicely fit every user into this category and some users will want to directly run upstream releases and continue to get minor bug fixes on older branches, this is just where we have drawn the line so far and welcome more feedback.

I strongly suggest backport. We will not upgrade to 1.5 soon. And a lot of user still use 1.4.

Firstly, we also recommend backporting this into your internal 1.4 branches along with any other fixes for bugs you are experiencing on that branch.

Let me try to explain our reasoning here and see if this change would apply since whether it is necessary in the branch is subjective. We added the extended support to mean we consider the branch to be stable and will only be doing releases for security issues or high impact stability issues. The attitude of "we will not upgrade to 1.5 soon" applies to many who prefer to be on the most stable version of software. By putting changes onto this branch, any release for a security or serious issue will also include this change. The feedback we have gotten from these more conservative users is that they would prefer to keep these releases smaller in scope because they are seen as must update releases, while also they are perfectly fine carrying the other patches they deem most important to them. We realize we cannot nicely fit every user into this category and some users will want to directly run upstream releases and continue to get minor bug fixes on older branches, this is just where we have drawn the line so far and welcome more feedback.

@dmcgowan I understand the community wants to maintain less branches and wants to push users to use newest version. Yes we are users that want to use most stable version. As we have use release-1.4 in production environment, it is not easy for us to upgrade to 1.5 or 1.6. We MUST keep production environment stable. And this pulling image issue is kind serious for big image pulling. I think it is not a small fix. So I do hope community can release a new tag for release 1.4

Any updates on this issue? We are running into this issue and it's not exactly easy to upgrade to v1.5.

Can you rebase on HEAD of release/1.4 to pick up a fix for tests to run properly? Thanks!

v1.4 reached EOL
fdaf859