On 2008.04.18 15:06:10 +1000, Jonathan Lange wrote:
CompatibilityPolicy suggests release-based deprecation that is graded over 4 releases: release N PendingDeprecationWarning, N+1 DeprecationWarning, N+2 DeprecationError, N+3 remove the functionality.
Ticket #1216 suggests a release-based deprecation policy that is not graded and over 1 release: release N, add DeprecationWarning, release N+1, remove the functionality.
As a user, I don't see much difference between a PendingDeprecationWarning and a DeprecationWarning. Or between a DeprecationError and the code being removed. Simple is good.
Now, here's what I think.
* Release-based, not time-based.
Now that version numbers are based on the year, there's not a big difference. For example, if you wanted to guarantee at least a year of DeprecationWarning before removing a feature, you could implement that by saying that if the warning goes in in 8.x, then the feature can come out in 10.0. Or vice-versa. -- David Ripton dripton@ripton.net