[gsnedders]

This is exactly the sort of breaking change that I really struggle to see the value of — maintaining the deprecated method seems incredibly unlikely to be a notable maintenance burden when it is literally just:

    @deprecated("Use response.headers.get(name) instead")
    def getheader(self, name):
        return self.headers.get(name)

Like sure — deprecate it, which might have _some_ downstream cost, rather than having two non-deprecated ways to do the same thing, just to make it clear which one people should be using; but removing it has a much more significant cost on every downstream user, and the cost of maintenance of the old API seems like it should be almost nothing.

(I also don't hate the thought of having a `DeprecationWarning` subclass like `IndefiniteDeprecationWarning` to make it clear that there's no plan to remove the deprecated function, which can thus be ignored/be non-fatal in CI etc.)

[eglintondust]

There is value for the person maintaining this library cause they want it that way. If you develop a useful library and give it away for free then all power to you if you want to rearrange the furniture every 6 months. I'll roll with it.

[Wowfunhappy]

I definitely agree with the sentiment that people working for free can do whatever the heck they want.

But if you're trying to help your users and grow your project, I think GP's advice is sound.

[gsnedders]

You are, of course, correct.

But the fact that they made a new release with it undeprecated shows they _do_ care about their users (direct and indirect), and at least from my point of view (both from the Python ecosystem and the browser ecosystem) this was a pretty foreseeable outcome.

[mxey]

> If you develop a useful library and give it away for free then all power to you if you want to rearrange the furniture every 6 months.

That would make it no longer a useful library