#3040 enhancement new
Set version information in new deprecations to the version number actually associated with a release
|Reported by:||exarkun||Owned by:|
|Priority:||normal||Milestone:||totally automated release infrastructure|
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.