Hello Pakal, If I understand correctly, you're proposing that:
1. The Django project should maintain a higher level of backwards compatibility. 2. This would be easier to achieve outside the main codebase, in a submodule or in a separate repository. 3. This would reduce the amount of work required for maintaining Django (triaging tickets, fixing bugs, adding features). Backwards-compatibility is a major concern for the development of Django, as you can see from in contribution documentation, in the archives of this mailing list, in DEPs, etc. Maintaining more compatibility with the same effort or less should be uncontroversial. Now the question is to get consensus that your proposal will indeed achieve the stated goals. I'm quite skeptical of the "same effort or less". The more behaviors Django maintains — and you're proposing essentially to maintain all behaviors that existed at all previous releases — the more complexity accrues. You can't solve that just by shuffling deprecation warnings or compatibility imports in another module (and it seems to me that it would be harder to maintain, for the reason the Python ecosystem usually eschews monkey-patching: non local effects). Keeping old ways around forever increases the barrier to mastering Django for people who haven't been writing Django code for ten years like you and me. It also increases the scope on which compatibility must be maintained, and that can get in the way of making Django better. One way to frame the debate is: does Django aim at being a fossilizing ecosystem or a living one? Up to this point, we've chosen to maintain a living ecosystem. At a given point in time, all maintained libraries support 2 or 3 versions of Django (latest, previous, LTS). Things change a bit; unmaintained libraries that don't adapt fall out of favor; new libraries build upon the experience of previous ones and try to do better. One can see this as progress and a way to keep up with the moving web ecosystem. One can also see this as useless churn. As you call it "walk or die", it's pretty clear which camp you're in :-) I'd say there's truth in both! As an experiment, let's just consider the first backwards-incompatible change from the latest release: https://docs.djangoproject.com/en/2.2/releases/2.2/#admin-actions-are-no-longer-collected-from-base-modeladmin-classes <https://docs.djangoproject.com/en/2.2/releases/2.2/#admin-actions-are-no-longer-collected-from-base-modeladmin-classes> (I'm skipping the database backends changes because they're explicitly out of the backwards-compatibility policy, but we started documenting them for the maintainers of third-party database backends.) This is a good example. Django behaved in a non-Pythonic way; it didn't respect the Principle of Least Astonishment. Since we believe Django is alive and will have infinitely more future users than past users, we make the change. How can we maintain backwards-compatibility for this? We can try to detect if subclasses have all the actions of their parent classes and, if not, raise a warning. But then we raise inappropriate deprecations warnings in legitimate use cases where a subclass mustn't have some actions of its parent class, which is probably the use case for which this change was requested. Experimenting with a third party module like you did is absolutely the way to go. You're already ahead of the usual advice :-) Keep in mind that the barrier for making a third-party project an official Django project or to merging it in Django is very high. With 1 fork and 2 stars, django-compat-patcher doesn't pass it yet. Writing a DEP to formalize arguments on both sides is a valid idea. Don't forget the other side. In your freecodecamp article, you're spending two lines on the downsides of Compat Patchers, and this is not enough. How would Django communicate to users which backwards-incompatible changes are covered by Compat Patchers and which aren't? How would we respond to users asking for a Compat Patcher for a backwards-incompatible change for which it's impossible? Eventually, will every library document the list of Compat Patchers it requires or it's incompatible with? As you can see, there's more than "blinding self-absorption" and "harmful psychological bias" here. Your freecodecamp article makes valid points. It also misses completely what's hard in maintaining backwards compatibility. I wish you hadn't found it useful to insult the work put into managing backwards-compatibility over the years and the people who did it. Best regards, -- Aymeric. > On 29 Jun 2019, at 13:09, Pkl <chambon.pas...@gmail.com> wrote: > > Hello everyone, > > I'm planning on writing a PEP on long-term API stability for Django. > Most of the rationale behind this kind of commitment is described here : > https://www.freecodecamp.org/news/api-stability-is-cheap-and-easy/ > > The idea is that the django ecosystem has suffered a lot, over the past > decade, from the numerous breakages happening at each (minor) release. I > could write pages just about what "outsiders" like me endured regarding > neverending URL patterns changes. > > Lots of pluggable apps, and their own plugins and bridges, have become > incompatible with each other due to sticking to different django versions, or > to lack of Tox-like cross-version testing. Some undocumented breaking changes > (like classes replaced by other ones but missing functionality, or laziness > introduced without autoloading measures for backwards compatibility > (RequestContext?)) also hindered misc projects, as seen in their bugtrackers. > > With *less* work than currently, except small changes in procedures, we can > revive the majority of existing packages (except python2vs3 troubles), > currently maintained or not, and make upgrades much smoother, which will also > improve the overall security of django-backed sites (since users won't fear > upgrades anymore). We can thus reach the same regard for compatibility as > most industrial-size ecosystems, without sacrificing the cleanness of the > codebase, nor its maintainability. > > For this, imho the best way is just have to include in Django official > support for a companion library like > https://github.com/pakal/django-compat-patcher , with which I've had immense > success > > There are several ways of doing this, and for this more thoughts are > necessary: > > - putting compatibility sets in the repository, as a django.compt submodule > for example? > - putting them in an external repository, but strongly advising them in > tutorials and otehr docs, like a prime "official project" of django? > > There are probably aspects of the issue that I'm missing, as I'm not into > django "core" development. > So your feedbacks are more than welcome! > > Thanks, > regards, > Pakal > > -- > 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/1d2f1399-3310-4b36-ae74-9581a0695002%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/1d2f1399-3310-4b36-ae74-9581a0695002%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9750CEF0-2380-40A3-A54F-88CDA50F58F7%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
