One solution is to create a RemovedInFutureVersionWarning to allow projects to catch the change when running with -Wall, without committing to a specific release.
On Wednesday, December 30, 2015 at 3:05:32 PM UTC+1, Tim Graham wrote: > > To save a link click, the question is about moving > django.core.urlresolvers to django.urls and whether or not to start the > deprecating of django.core.urlresolvers immediately. > > I don't have a strong opinion myself. On one hand, delaying gives projects > more time to update, on the other, I suspect many projects will continue > using django.core.urlresolvers in new code if there's no indication that > it's deprecated. > > On Wednesday, December 30, 2015 at 8:50:10 AM UTC-5, Marten Kenbeek wrote: >> >> As noted >> <https://github.com/django/django/pull/5578#discussion_r44212450>by >> Collin on deprecating old import paths: >> >> I personally wouldn't mind if we didn't actually deprecate this, and left >>> these shims in a bit longer :). (Makes it just a hair easier for people >>> upgrading.) But that's just me. >> >> >> There is very little maintenance overhead to keep backwards-compatible >> import shims longer than the current deprecation cycle. >> >> Any thoughts on this? >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4a0e4865-b4b4-4aaf-af91-2cdc77965839%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
