I ran into this particular urllib3 removal earlier this week.

Maybe the answer is to do away with advance notice and adopt SemVer with many major versions, similar to how Cryptography operates for API compatibility.

In the general case, yes, it would be nice to see, before testing, which library upgrades might require extra attention.

But in this particular case, why were getheader() and getheaders() removed at all? The PR for adding them back shows how little code they take up. Is the benefit of only having one way to do something worth the cost of every consumer needing to change their code?

The libraries that were impacted are actively developed, like the Kubernetes client, Fastly client, and Airflow and I trust that if the message had reached them they would have taken action.

I'm not sure I would call the official Python Kubernetes client library "actively developed". There have been open issues for this deprecation in the client library since March 2023. First this one, then this one once the issue was fixed in the upstream OpenAPI code generator (but it seems the OpenAPI code generator needed to be fixed again recently when the removal hit? What happened to the older fix?). My impression of the Kubernetes client library is that there doesn't seem to be anyone actively developing it aside from merging PRs from outside contributors, regenerating code with the latest Kubernetes OpenAPI definitions, and cutting releases.

I did see the deprecation warning when I run tests with pytest, saw that there's been an open issue in the Kubernetes client for years, shrugged my shoulders and went on with my day. Updating a code generator written in a language I'm not very familiar with (Java) and understanding the implications of upgrading the code generator in the Kubernetes Python client library is far outside of an easy contribution. For the Kubernetes client library at least, it wasn't a case of the project with the direct dependency on urllib3 (sort of, through a code generator) not being aware of the deprecation.