id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
37080	Django's own tests should always treat both Django deprecation warnings as errors	Mike Edmunds		"Django's runtests.py treats RemovedAfterNextVersionWarning (currently equivalent to RemovedInDjango70Warning) as an error, in all releases. And in x.0 and x.2 releases, it also treats RemovedInNextVersionWarning as an error. 

However, in x.1 releases RemovedInNextVersionWarning is ''not'' handled as an error (because there is no RemovedInDjango62Warning, or any x.2 equivalent).

This doesn't matter for most Django tests, which use the concrete RemovedInDjango70Warning, RemovedInDjango71Warning, etc. But it complicates testing Django's own deprecation utilities and assertion helpers, and it [https://code.djangoproject.com/ticket/37072#comment:8 makes discussions of them complicated].

Suggestion: change runtests.py to use the ''generic'' warnings and treat them ''both'' as errors—always, without the need to advance them each release:

{{{#!python
# Before:
warnings.simplefilter(""error"", RemovedInDjango70Warning)

# After
warnings.simplefilter(""error"", RemovedInNextVersionWarning)
warnings.simplefilter(""error"", RemovedAfterNextVersionWarning)
}}}


(I think this becomes moot if/when we switch to calendar cycle releases.)"	Cleanup/optimization	new	Testing framework	dev	Normal				Unreviewed	0	0	0	0	0	0