Django 1.4 compatibility

[jvamvas]

As a long-term support release of Django, version 1.4 is still widely used (extended support ends on October 1, 2015). It would be nice if django-watson would support those projects.

Making use of the django-compat package, we can re-route all import statements that would otherwise fail on Django 1.4. This allows us to achieve backwards compatibility with minimal code changes.

[etianen]

Thanks for the pull request! :)

However, I'm not sure that complicating the code base and adding an external dependency is worth it to provide compatibility with a django release that will end long term support in 15 days!

[philippeowagner]

@etianen adding django-compat would also help to handle for- and backward compatibility in the future. Our main issue is that we are still in the process of upgrading client projects from 1.4.x to 1.8.x - and I know that we are not the only one ;-)

[etianen]

I'm still not convinced. Django has made the decision to deprecate and eventually remove parts of its codebase to maintain long term readability and prevent bloat. Moving all of this removed code into a "compat" package just recreates the problem they're looking to solve. What's to stop django-compat just growing and growing? If deprecation by the core team isn't a reason to drop a feature, what is?

On Mon, 14 Sep 2015 at 20:00 Philippe O. Wagner notifications@github.com wrote:

@etianen https://github.com/etianen adding django-compat https://github.com/arteria/django-compat would also help to handle for- and backward compatibility in the future. Our main issue is that we are still in the process of upgrading client projects from 1.4.x to 1.8.x - and I know that we are not the only one ;-)

— Reply to this email directly or view it on GitHub https://github.com/etianen/django-watson/pull/124#issuecomment-140176456 .

[philippeowagner]

Good points about deprecation. The idea behind django-compat is not to bypass it at all.

• Be able to use the LTS versions of Django and support newer versions in your app
• Use features from newer Django versions in an old one
• Manage and master the gap between different framework versions

The most things in compat are methods that were moved around in the framework and still does the same thing. A lot of projects have a compat.py file or compat code and these bits of code are not DRY - especially when looking beyond the app "border".

For example, #106 could be fixed with it in all apps.

Anyway, it was a proposal.

[michaelkuty]

When i thihnking about this topic, i'm sad because these things happens in every framework and making something like django-compat is good idea but, making compatibility to this library is bad idea, if you want you can create fork and make this happens, but easiest way is migrating your django project to latest LTS instead of creating useless backward compatibility layer

i forgot my vote to this PR :-1:

[etianen]

Thanks to everyone for your opinions here! Github is a great place to be. :)

On Mon, 5 Oct 2015 at 14:08 Jannis Vamvas notifications@github.com wrote:

Closed #124 https://github.com/etianen/django-watson/pull/124.

— Reply to this email directly or view it on GitHub https://github.com/etianen/django-watson/pull/124#event-426753452.