Yep. The Document related stuff keeps bugging headless users ;)

You could also add a deprecated/3.8

We do now have an issue if we are doing much faster releases where methods will drop away too quickly for the casual user (ie. the vast majority of normal sane people).

If we are doing a June 1 release that is only 3 months. Maybe we should move the release back to August. Let's discuss what a good regular release period is.

We could agree to leave 3.8 deprecated things in (but deprecated) until 3.10

Possibly there are many people who are moved or are just now moving to 3.7 from 3.6 and they are only just noticing these deprecated methods. Come June 1 they would be rudely removed. So maybe don't remove until 3.9.

We could discuss the policy on the list. Write it up on the wiki.

Yes, that seems good. we could add a field in the deprecated method, so that the code says when it will happen.

might be a good idea to move this to a backwards-compatibility quark so that old code won't necessarily break. also, some of the methods didn't emit a warning, so it might be reasonable to keep them around for one more release (with a deprecation warning added)

We all agreed but nobody actually did it. They are removed in the 3.8 release (which will get merged into master)

Now master is the 3.9 track and I;ve proposed the same thing: remove deprecated 3.8 now.