[RFC] Major breaking changes in the upcoming release

[roycaihw]

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:

• migrate from swagger-codegen to openapi-generator gen#93
• feat: switch python client to use openapi-generator gen#97

Major breaking changes were detected when we released 11.0.0a1 with openapi-generator:

• Changelog
• 11.0.0a1 release page
• 11.0.0a1 release PR

The breaking changes are:

1. [Major] kubernetes.client.apis package is renamed to kubernetes.client.api
2. [Major] kubernetes package code now uses absolute import instead of relative import
3. [Minor] The swagger_types attribute in all models is renamed to openapi_types

the major breaking changes come from swagger-api/swagger-codegen#6839 (comment), 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?:

• All 8.0.x, 9.0.x, 10.0.x versions are not affected
• 11.0.0a1 (corresponding to Kubernetes 1.15) is the only version that's affected currently
• The next release 11.0.0b1 and future releases (corresponding to Kubernetes 1.15, 1.16+) will be affected.

Impact and fix:

• All clients that import kubernetes.client.apis must change the import to kubernetes.client.api when upgrading to 11.0.0b1+, to avoid import error.
• Clients that use relative import and patch the kubernetes package locally may experience unexpected import error. Clients should install kubernetes package properly following the instructions in the Readme or the release page.

[roycaihw]

cc @dims @fabianvf @mbohlool @micw523 @oz123 @scottilee @tomplus @yliaog (apologies if i have missed anyone)

[oz123]

@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

[tomplus]

@oz123 there are more changes than renaming modules so it'd be still important to watch out when upgrading to the proposed version.

[oz123]

@tomplus , thanks for the hint. I will definitely try to make aliases for all the breaking changes, so breaking isn't breaking, rather warning.

[fejta-bot]

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

[avarf]

Hi,
Any news regarding 1.16 support? Or the the estimated release time?

/remove-lifecycle stale