TLDR; Introducing django-compat - arteria's solution for for- and backwards compatibility from Django 1.4.x to 1.8.x./1.9.x
SITUATION We really love how Django evolves and how the core gets better and better. New major versions of the framework that comes with changes, bugfixes and new features are released quickly. This is great and nothing is wrong with that! But there are issues from the business/agency/our point of view: * We are not as fast as Django is * We have reusable apps that must work with multiple Django versions and * We have a lot of these apps, open and closed source A lot of (3rd party/open source) apps * ignore older Django version due to the additional effort or * have this try/except pattern everywhere in the code or * encapsulate them in a per app compat.py file, see a some example in the projects README All our "reusable apps" for client project and products where built on and for the Django LTS 1.4 version. With the release of the new LTS version we started every new project on 1.8, but still have all other older projects that runs on 1.4 and depends on these apps and it's update that must be compatible with both versions in our case. SOLUTION To handle this problem we created django-compat [1], which is something similar to six. The goals of django-compat are: * Eliminate code duplication from app to app and handle them in one central place. * Make apps working with multiple Django version and provide a backward compatibility * Bringing things that are availbale in newer releases (sth. like importing from future) into older one * Have a stable and testet single library that handles these compatible objects ... CURRENT STATE / WHATS NEXT We are using this library/approach successful in production on our clients project, in our products and its in open source apps. Eg django-hijack, django-background-tasks, ... to provide best possible stability It's tested using the test cases that are shipped with Django itself. So it provides for- and backward compatibility between Django versions (we basically cover what is supported by Django itself and (will, WIP) align to the official releases. We already started to integrate 1.9 support. Next will be to add more of 1.9 and more tests. We are aware that there are some issues with the approach in some cases. Eg the get query set renaming. [2] I'm curious what you think about django-compat and if it would also simplify your other djangonauts' life. Regards, Philippe PS I: I'm introducing this on the developer mailing list due to a chat on the DjangoCon Europe with Loic Bistuer. PS II: This thing was discoussed already on reddit. [3] [1] https://github.com/arteria/django-compat [2] http://lukeplant.me.uk/blog/posts/handling-django%27s-get_query_set-rename-is-hard/ [3] http://www.reddit.com/r/django/comments/2jrr4l/whats_the_best_practice_to_provide/ -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c1ee522c-5b58-464b-8954-3808f9f0274a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
