On Wed, 2014-09-03 at 14:46 +0200, Aymeric Augustin wrote:
> 1.5 and 1.6 must have been easier than 1.4. 1.7 may be more difficult > because > of migrations and app-loading. If anyone has improvements to suggest > for the > documentation, please do! We could perhaps have better documentation of how to handle deprecations in 3rd party libraries. Namely, how to remove usage of deprecated features in a way that works silently both before and after the addition of the deprecation. For example, lets consider the get_query_set() -> get_queryset() naming change done in 1.6. If 3rd party library writers change the method name to get_queryset() for 1.6, then their code won't work in 1.5. If they don't do the change, then all users trying to run with -Wall will get a bunch of deprecation warnings they can't do much about. This will effectively ruin the "run with -Wall" advice. The usual way to solve these kinds of problems in code that needs to work in multiple Django versions is to write code which is conditional on Django's version. It looks a bit ugly to define methods conditionally, but in practice this works extremely well. So, when adding a new deprecation to Django, we should document how 3rd party library writers can write code that works *silently* both before and after the feature deprecation is added. If there is no easy way to achieve that, then we should reconsider the deprecation. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1409750485.11410.611.camel%40TTY32. For more options, visit https://groups.google.com/d/optout.
