Given that alternate, I guess I'm not really enthusiastic about making our deprecation policy more complicated. While urlresolvers is a commonly used module, updating should be a simple find and replace for the imports.
On the other hand, I thought of a slight flaw in our current deprecation scheme. If a third-party library wants to support both 1.8 and 1.11 (next LTS) would have to use a try (new import)/except (old import) pattern to avoid code running on 1.11 from raising deprecation warnings (some pending deprecation in 1.10, deprecated in 1.11, and removed in 2.0). In my mind, part of the purpose of the new policy was to avoid this type of complexity. For that reason, I think we should reconsider making Django's deprecation warnings loud by default (at least in LTS versions) [1]. Otherwise, users will pester library authors to fix those warnings and we haven't really made things easier. Instead, the idea would be for library authors to continue using the deprecated APIs while supporting the LTS in which they are deprecated and the previous LTS. When the version of Django following the LTS is released, library authors can then drop support for all Django versions before the LTS, check their package with the LTS using python -Wall and make the deprecation warning fixes, then seamlessly add support for the next version of Django. Does that make sense? [1] slightly related: https://code.djangoproject.com/ticket/25999 On Wednesday, December 30, 2015 at 10:28:02 AM UTC-5, Marten Kenbeek wrote: > > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/fbc27057-331f-4d7e-b411-a656f75cd7d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
