Opened 3 years ago
Last modified 3 years ago
#33518 closed Cleanup/optimization
Add alias RemovedAfterNextVersionWarning for deprecations after next version — at Initial Version
Reported by: | Shai Berger | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
For a very long time, we've had in django.utils.deprecation
something like this (from the 3.2 source code):
class RemovedInDjango40Warning(DeprecationWarning): pass class RemovedInDjango41Warning(PendingDeprecationWarning): pass RemovedInNextVersionWarning = RemovedInDjango40Warning
Or (current master, towards 4.1):
class RemovedInNextVersionWarning(DeprecationWarning): pass class RemovedInDjango50Warning(PendingDeprecationWarning): pass
I suggest that we add an alias, RemovedAfterNextVersion
for the PendingDeprecationWarning
subclass.
The motivation is to make it easier for long-running projects to prepare for future deprecations, with scripts that run tests with special filters on the relevant warnings; currently, such scripts need to be updated for every version. This is especially important for projects which stick to LTS versions, as for them, both warnings need to be treated the same.