On Tue, May 5, 2020 at 2:24 PM Collin Anderson <cmawebs...@gmail.com> wrote: > If exception/special treadment is an issue, then I'd suggest making this an > official policy change going forward. I would be much happier if all of the > examples you gave were still around with warnings. All of those upgrades were > annoying. I think an ultra-ultra-extended deprecation cycle would be a good > precedent. I think it makes Django more attractive as a potential platform > for people to build their website on. I don't see it getting in the way of > future evolution. Could you say more?
If you'd like Django to commit to never removing anything, and instead to preserve every piece of documented API forever, I'm sure the DSF will be happy to accept the generous monetary donation you no doubt intend to make in order to assist with that task, which I assume you'll be willing to provide on an ongoing basis for... well, forever. An initial contribution of a few million would help to get this rolling, and we could set up recurring billing for the future payments. And I'm not joking about that. Every piece of deprecated code is a maintenance burden; it requires keeping full regression tests around and responding to bug reports and considering the possible interaction of every new feature that ever gets introduced. All of which comes at a cost of time and effort and -- if it's done by the Django Fellows, which a lot of that work is -- a cost of literal cash money out of the DSF's pocket. Or we could allow Django to continue shedding deprecated APIs on a predictable and documented cycle. I really do understand that it's annoying to put in the effort to keep up to date. I lived through magic-removal. I've done multi-version upgrades of massive codebases basically by myself in the past. I remember them vividly, and I know they're not fun. And there are platforms out there which have the kinds of "nothing is ever removed" compatibility policies you're advocating for. But Django isn't one of them, and I don't think it should be or, at this point in its history, can be: to work at all, that kind of policy has to be introduced early on and has to be allowed to influence a lot of fundamental design decisions that, in Django's case, were already made many years ago. If we introduce such a policy now, the very first thing i'll do is go file a DEP asking for the old "magic" ORM to be put back, and manipulators along with it. Anyway. As Adam mentioned, there's a good reason to put the DEP 201 URL routing in front of people's eyes in a way they'll actually notice. Our only truly reliable tool for doing that is deprecation backed up by the knowledge that when we deprecate something, it will end up removed. DEP 201 set out a deprecation schedule for url(); in hindsight I wish it were shorter and just followed the normal post-2.0 policy of one LTS-to-LTS cycle, but at this point it's too late to change that. I'll still argue quite strongly that the deprecation period should not be made any longer, and I'll argue with every breath I can devote to Django that a "deprecate but never remove" policy should not be adopted. -- 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg8WAEBYF-TWYdCOLxknrYyLfC0tSVfHnM6xWtVWHCwyyw%40mail.gmail.com.
