Excuse the frankness of my reply, but I really don’t see the point in any of this.
Perhaps I am not working at a scale where this becomes a legitimate issue. However I have upgraded more Django projects than I could possibly care to count, usually between LTS versions. Almost all of these upgrades have occurred in an agency / contractor setting where every hour counts…so I am extremely sensitive to pointless API churn without benefit to the user. Django changes like the one being discussed (which is essentially a name change) have *never* been an area of concern when compared with actual changes to the mechanics of Django, and I am not saying that those changes are not warranted. I don’t believe that url() is enough of a special case that this proposal wouldn’t introduce a slippery slope scenario that’d result in a lot of deprecation shim cruft in Django. The mental overhead of dealing with a codebase filled with deprecation shims is taxing, and not something that I’d wish on volunteer open source developers. I am extremely thankful for Django’s deprecation process and its relatively long LTS periods. My experience has been that the current deprecation process is sufficient, and my feeling from my perspective as a Django ‘user’ is that it is sufficient in this case. Django should not be built with the premise that project code should never need to be updated. Practical (volunteer time) reasons aside, these sorts of policy decisions can leave a framework in the dust as it hinders evolution. Moving my projects from Django to something else because of an inevitable deterioration in Django’s comparative value proposition will take up way more of my time than replacing url() with re_path(), or even path()… I am sure that there are more 'enterprise-focused' web frameworks that offer the sort of support you are after. Perhaps something written in Java with a EULA? ;-). On 6 May 2020 at 5:43:01 am, James Bennett (ubernost...@gmail.com) wrote: 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. -- 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/CANK-yknvWUdQ574mMRFrtxoL0JPJe4Ppxxdw2fAEk5PZORf_nw%40mail.gmail.com.
