Hi Kubernetes Python client developers, this is a request for comment issue. Please leave comments if you have any opinion/suggestion. Thanks!
What happened:
A majority of the code base is generated code. This repo is switching from using swagger-codegen to using openapi-generator. For more backgrounds:
Major breaking changes were detected when we released 11.0.0a1 with openapi-generator:
The breaking changes are:
kubernetes.client.apis package is renamed to kubernetes.client.apikubernetes package code now uses absolute import instead of relative importswagger_types attribute in all models is renamed to openapi_typesthe major breaking changes come from https://github.com/swagger-api/swagger-codegen/pull/6839#discussion_r148603571, which is also in latest swagger-codegen. This repo didn't have these changes because we were depending on a old version of swagger-codegen.
What versions are affected?:
8.0.x, 9.0.x, 10.0.x versions are not affected11.0.0a1 (corresponding to Kubernetes 1.15) is the only version that's affected currently11.0.0b1 and future releases (corresponding to Kubernetes 1.15, 1.16+) will be affected.Impact and fix:
kubernetes.client.apis must change the import to kubernetes.client.api when upgrading to 11.0.0b1+, to avoid import error.kubernetes package locally may experience unexpected import error. Clients should install kubernetes package properly following the instructions in the Readme or the release page.cc @dims @fabianvf @mbohlool @micw523 @oz123 @scottilee @tomplus @yliaog (apologies if i have missed anyone)
@roycaihw my 2 cents (appologies for being so scrooge, it's late here):
I consider this "impolite" to remove existing functionality without warnings. Maybe we can add an empty package called api which only imports everything from apis.
However, when one uses stuff from api we can issue a deprecation warning. This package can stay along for 2 versions giving people enough time to update their code.
I'm willing to work a PR for this.
If someone else feels the urgency to do this before me here is a reference:
https://www.lesinskis.com/python_deprecation_tutorial.html
@oz123 there are more changes than renaming modules so it'd be still important to watch out when upgrading to the proposed version.
@tomplus , thanks for the hint. I will definitely try to make aliases for all the breaking changes, so breaking isn't breaking, rather warning.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Hi,
Any news regarding 1.16 support? Or the the estimated release time?
/remove-lifecycle stale
Hi @avarf, we are actively working on 11.0.0 stable release. After that we will start 12.0.0a1 release, which corresponds to Kubernetes 1.16
Hi @roycaihw and thanks for your works. Is there any rough timeline for these releases?
@palnabarun Nabarun is working on the 11.0.0 release and I think a PR will be created in the next two weeks.
/assign
@roycaihw I think all of the points here are taken care of and 11.0.0 had been released sometime back.
Shall this issue be closed?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Most helpful comment
@roycaihw my 2 cents (appologies for being so scrooge, it's late here):
I consider this "impolite" to remove existing functionality without warnings. Maybe we can add an empty package called
apiwhich only imports everything fromapis.However, when one uses stuff from
apiwe can issue a deprecation warning. This package can stay along for 2 versions giving people enough time to update their code.I'm willing to work a PR for this.
If someone else feels the urgency to do this before me here is a reference:
https://www.lesinskis.com/python_deprecation_tutorial.html