Re: Improving Backward Compatibility

> We'd likely deprecate fewer features if we had to reach consensus on django-developers every time I’m not sure if you consider this a good thing or a bad thing Aymeric :) I haven’t fully thought through a process but I’m not even sure a full consensus would be required. But it’d help to think t

Re: Improving Backward Compatibility

Hello, The duration of the deprecation period doesn't make a big difference because few people update their code until they have no other choice. Keeping deprecated code around longer means it's harder to track down the release where the corresponding changes were introduced and figure out what

Re: Improving Backward Compatibility

Following on from Collin, another ticket that generated a large amount of code churn for little perceived benefit was https://code.djangoproject.com/ticket/21127 (enforce on_delete). I know there are many in the community that rail against any and all changes (I had an argument with such a pers

Re: Improving Backward Compatibility

I don't see a strong reason to make it easy to support 1.8 and 2.0 at the same time. Support for Django 1.8 ends 4 months after the release of 2.0. As the 2.0 release notes say, "Following the release of Django 2.0, we suggest that third-party app authors drop support for all versions of Django

Improving Backward Compatibility

Hi All, I think it would help if Django was better at *deprecations and backward compatibility*. I’ve brought this up [before ], but didn’t get any feedback, so here’s another try at it, with some *specific ideas of ho