id	summary	reporter	owner	description	type	status	priority	milestone	component	resolution	keywords	cc	branch	branch_author	launchpad_bug
3040	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.
"	enhancement	new	normal	regular-releases	release management			thijs