Thanks Tim for your response and sharing the report of the survey. As mentioned in the introduction, we will (give our best to) keep aligned to the official releases and do not intend to bypass the security concept of Django. We will update the project README to communicate the concept correctly. https://github.com/arteria/django-compat/issues/28
Compatibility seems to be common issue. For internal use, we are interested in work from LTS to LTS. For our open source apps we want to support what's supported officially to not exclude others. That's why we started this thing. I'd really welcome the bi-yearly LTS release cycle with one year of LTS support overlap - the longer the better. Philippe Am Mittwoch, 3. Juni 2015 15:25:21 UTC+2 schrieb Tim Graham: > > When do you drop support for old versions of Django? The main concern I > have is that it somewhat encourages running on unsupported and insecure > versions of Django (currently 1.5, 1.6; and 1.4 will be end of life in > October). Therefore I don't thinking giving it an official blessing is a > good idea. > > In the "1.9 release planning" thread I proposed a new deprecation schedule > to make it easier for third-party apps to support the currently supported > Django versions now that we have LTS releases. Here's that proposal: > > > https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing > > Feedback on that will would be welcome. > > On Wednesday, June 3, 2015 at 6:14:39 AM UTC-4, Philippe O. Wagner wrote: >> >> 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/631f206c-5b06-4137-8c03-f24c2c728306%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
