Set version information in new deprecations to the version number actually associated with a release

[exarkun]

Some APIs (eg twisted.python.deprecate.deprecated) accept version information. This information can't be known for sure until a release is actually done (eg, a lot of deprecations, though they mostly don't use the API mentioned above, talk about Twisted 2.6, which presumably will not be the next version of Twisted). We should represent "the next version of Twisted" symbolically and part of the release process should be to replace this with an actual value.

Here's one humble suggestion:

• twisted.something is a Version instance set to a reasonable guess for the next Twisted release. Any new deprecations import and use it.
• When a release is about to happen, all imports of twisted.something are replaced with imports of twisted.somethingElse. twisted.somethingElse is the Version number which is actually associated with the release.
• twisted.something is updated to give a reasonable guess for the next Twisted release.

This way, it's always the same to deprecate an API (and particularly, it doesn't require much thinking about releases and such). It also gives deprecations a uniformity which should make the release update job straightforward.

[exarkun]

(In [22677]) Merge deprecated-enterprise-3022

Author: exarkun Reviewer: therve, dreid Fixes #3022 Refs #3040

Deprecate twisted.enterprise.util and everything in it.

[thijs]

Also see #3838 where a 8.2 vs 9.0 trunk issue is described.