I am weakly 👎 on removing the .. versionadded: notes. Although we do not plan to provide bug-fix releases for any of the old versions, there is definitely a lot of use of older versions in the wild.

We don't use .. versionadded:: anywhere else, and have not used it consistently in this toolbox. Does it really make sense to keep it?

versionadded is generally a helpful concept. However, only having it for very few functions is not a great help. It's rather making me wonder why I don't see that info on other functions and if that missing tag means they are older than any explicitly mentioned version.

Since we don't have it and nobody wants to take the effort of adding it for large parts of the library, I'm +0.5 on removing the entries for consistency.

My thought is that since 2.0 made default changes, you probably don't want to go any older than that, so any versionadded before that is noise. But anything newer than 2.0 probably has a What's new? entry, so probably doesn't need the tag either.

Oops, misclick there.

The effect of these is just to include a "what's new" or "changed in" note to the documentation. Including such notes for things added in 2011 does not make any sense to me unless the intention is to do that for the entire API. Having these for new things does make sense, but I was asked to remove such a note in my recent PR, so consistency is already a problem.

Consistency would also be important because if I saw a "what's new in 3.3.5", I'd be led to believe all such additions to 3.3.5 would say so. So it should then be another thing to require and check in every new PR.

Then the question becomes how long you keep them. Not that I've looked closely, but Python docs seem to keep them for the current major version number (see https://docs.python.org/3/library/hashlib.html for examples) and I've been happy with that.

I think overall we're in favour here, and I'd rather fix CI. One can always revert if strongly feel like adding those everywhere.