Re: Some thoughts on upgrade pain & deprecations.

Picking this up in trac: https://code.djangoproject.com/ticket/26713 And github: https://github.com/django/django/pull/6732 On Thursday, 2 June 2016 16:00:26 UTC+1, Tom Christie wrote: > > > I'm against adding custom behavior in Django > > That's entirely reasonable, yes. > > In which case, what

Re: Some thoughts on upgrade pain & deprecations.

> I'm against adding custom behavior in Django That's entirely reasonable, yes. In which case, what do folks think of the following suggestions: * Linking prominently to the 'upgrading django ' section from at the begining of every

Re: Some thoughts on upgrade pain & deprecations.

> > Aside: I think the `.urls = ...` -> `@override_settings(ROOT_URLCONF=...)` > change to test cases is missing from those notes? > The 1.10 release notes say, "SimpleTestCase.urls is removed." > I expected to have seen a deprecation warning when running the tests under > 1.9, although

Re: Some thoughts on upgrade pain & deprecations.

I like the general idea. Going with your low tech solution we could have snippets for the X most popular test runners to treat warnings as errors. Perhaps ./manage test.py --warnings-as-errors or similar for the interface django provides. Every time django makes a release there are some that

Re: Some thoughts on upgrade pain & deprecations.

The low tech solution to this, may just be to have the release notes recommend running your test suite using `PYTHONWARNINGS=once`, and making sure not to swallow any output, eg. with py.test that'd be... PYTHONWARNINGS=once py.test tests -s I'm fairly sure that making that point explicitly

Some thoughts on upgrade pain & deprecations.

I've just finished upgrading Django REST framework to support 1.10, and it's given me some food for thought on things that can make Django upgrades painful. Firstly, here's a couple of things that I needed to track down in order to upgrade that weren't obvious at first... * A bunch of test