-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CRD] Delete CRD v1alpha1 #1771
Conversation
With this removal... aren't we giving too little time for users/developers to migrate? For example, in Kueue we currently support v1alpha1. Migrating to v1 could be risky, as we wouldn't be able to support kube-ray 0.x at all. And staying in v1alpha1 means that we would not be able to support 1.1.y. So the only alternative for Kueue would be to support both and a mechanism to detect which API versions are supported, which is a big investment (see kubernetes-sigs/kueue#1435 for POC). |
If, instead, you revert his change and keep v1alpha1 for 1 or 2 more releases, Kueue can support just v1alpha1 for a bit longer, and it would give users more time to upgrade kueue or kube-ray independently. |
Oops, I didn't know there were KubeRay-specific codes in Kueue. Is there any timeline for #1435? KubeRay 1.1.0 still needs at least 1 month to release. |
It is possible that #1435 could be finished within the next month, but it's a non trivial piece of code that I would prefer not to merge if it can be avoided. If KubeRay 1.1.0 still supports v1alpha1, we could migrate to v1 by the time 1.2.0 is released, giving enough time for users to upgrade KubeRay from 0.x to 1.0 or 1.1, before upgrading Kueue. |
Got it. I will revert the change. Thanks! |
This reverts commit d723f50.
Why are these changes needed?
#1492
Related issue number
Checks