#3040 enhancement new
Set version information in new deprecations to the version number actually associated with a release
|Reported by:||Jean-Paul Calderone||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:
Versioninstance 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.somethingare replaced with imports of
twisted.somethingElseis the Version number which is actually associated with the release.
twisted.somethingis 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.