/assign

I want to try this

/assign

I want to try this

Welcome! Please refer to https://github.com/volcano-sh/volcano/blob/master/docs/design/adapt-k8s-todo.md.

/assign
I want to try this

Welcome! Please refer to https://github.com/volcano-sh/volcano/blob/master/docs/design/adapt-k8s-todo.md.

OK, Thank you very much.

Do we need to have forward compatibility with previous versions of Kubernetes when performing e2e tests? For example, do we need to ensure compatibility not only with version 1.30 but also with versions 1.27, 1.28, and 1.29?

Do we need to have forward compatibility with previous versions of Kubernetes when performing e2e tests? For example, do we need to ensure compatibility not only with version 1.30 but also with versions 1.27, 1.28, and 1.29?

just test with the version we will support is ok.

Do we need to have forward compatibility with previous versions of Kubernetes when performing e2e tests? For example, do we need to ensure compatibility not only with version 1.30 but also with versions 1.27, 1.28, and 1.29?

just test with the version we will support is ok.

Yes, I understand that we only need to support version 1.30. What I mean is whether, in the long run, we should introduce tests for multiple versions in our e2e testing. This is because we are unsure if changes made in a pull request might impact previous versions. For example, if I submit a pull request that passes the kind e2e tests for version 1.30, it may not pass in versions 1.28 and 1.27.

Do we need to have forward compatibility with previous versions of Kubernetes when performing e2e tests? For example, do we need to ensure compatibility not only with version 1.30 but also with versions 1.27, 1.28, and 1.29?

just test with the version we will support is ok.

Yes, I understand that we only need to support version 1.30. What I mean is whether, in the long run, we should introduce tests for multiple versions in our e2e testing. This is because we are unsure if changes made in a pull request might impact previous versions. For example, if I submit a pull request that passes the kind e2e tests for version 1.30, it may not pass in versions 1.28 and 1.27.

You're right, it's better to cover all versions: )

Do we need to have forward compatibility with previous versions of Kubernetes when performing e2e tests? For example, do we need to ensure compatibility not only with version 1.30 but also with versions 1.27, 1.28, and 1.29?

just test with the version we will support is ok.

Yes, I understand that we only need to support version 1.30. What I mean is whether, in the long run, we should introduce tests for multiple versions in our e2e testing. This is because we are unsure if changes made in a pull request might impact previous versions. For example, if I submit a pull request that passes the kind e2e tests for version 1.30, it may not pass in versions 1.28 and 1.27.

You're right, it's better to cover all versions: )

Yes, I will follow up on this matter and raise an issue to track it after other PRs have progressed to a certain extent.

/assign

I want to try this

Thank you！But please note to control the pace, as the commercial version of Volcano relies on the community version for upgrades. We expect the community version to complete the adaptation by mid-July.