> Even if it will not be fixed for older versions, Django 4.1 ought to be eligible for a backport.
What you're suggesting is a change to the backport policy. That may be the right thing to do, but it would be quite a significant change. These issues — where a bug report/fix comes outside the backport period — are quite common. It's always a bit frustrating that we can't backport, but the stability of released versions has been taken (for years, by the whole community — by the folks hitting the particular non-backported issue this time :) as correct on balance. > But this response to it is eroding my trust in Django, and I hope you know that is not something I say lightly. Since I'm the only person who's responded thus far, I can't help but read that as saying it erodes your trust in me. That's sad. Especially since all I've done is not agree with you. :) Nonetheless you can invoke the Steering Council if no-one else responds, and you feel it's as bad as all that. > ...a critical time when Django is facing stiff competition... Django's USP is stability and ease of update, not async. The backport, stability, and supported versions policies are the cornerstone of that, I believe. It's not something we should endanger. Other frameworks move faster, but they don't have extended LTS lifetimes to consider. I see the success of FastAPI in particular. Super. But I don't see it as any different to Flask, say, in the previous period. May a thousand flowers bloom. I don't see it as an existential threat to Django. Quite the contrary: What a rich and wonderful time it is for the Python web framework ecosystem as whole. (This ecosystem is itself under threat from JavaScript, I'm constantly told, which will not survive Rust, I hear, ... and so on.) My view is that Django's async support is maturing nicely, slowly, but nicely and it's grows every release. That will continue for a few more cycles yet. Bug fixes in new features should be backported within the policy yes, but not beyond that. Better guidance in the asynchronous support docs saying, "hey, do update, this stuff is still growing" may well be in order. I have this in the Channels 4.0 release notes <https://channels.readthedocs.io/en/latest/releases/4.0.0.html#updated-python-and-django-support>: "The async support in both Python and Django continues to evolve rapidly. We advise you to always upgrade to the latest versions in order to avoid issues in older versions if you’re building an async application." — I don't think similar in Django would hurt. /my view. > ...as unwilling to support ... Following the backport policy is not being unwilling to support. Sorry (again) that I don't share your view. Sorry that undermines your faith (in me) — I assume we still think there's room for rational disagreement on how to weigh competing concerns in these kinds of cases. I'm going to mute this thread until after the new year now. Enjoy the festivities. Kind Regards, Carlton On Fri, 30 Dec 2022 at 11:34, James Bennett <ubernost...@gmail.com> wrote: > > > On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson <carlton.gib...@gmail.com> > wrote: > >> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that >> means if you're using those on older versions of Django, you'll need to >> work around. >> This is no different than any of a thousand other cases where there's >> been a bug in an older version that folks have needed to account for. >> > > I believe it is very different and have explained why repeatedly. > > But if it is to be left unfixed, what is the plan for how to communicate > the workaround to people who will be running into this bug until at least > April of 2024? And what is the plan for communicating to them that Django > is aware async testing is broken and the official policy is to knowingly > leave it broken in every currently-released version of the framework? Even > if it will not be fixed for older versions, Django 4.1 ought to be eligible > for a backport. And I strongly urge allowing a backport to 4.0 and 3.2, > though I do not know what could convince you at this point. > > This bug is bad. But this response to it is eroding my trust in Django, > and I hope you know that is not something I say lightly. I think it also is > going to erode the trust of other people when they find out about it, and > is going to do so at a critical time when Django is facing stiff > competition in the async space and cannot afford to lose more ground or be > seen as unwilling to support its own claimed async features. > >> -- > 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/CAL13Cg_5wFeiQjEbOfRYJGgZ2Hn3cQoJHoW-CSUSGD9xuNehoA%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAL13Cg_5wFeiQjEbOfRYJGgZ2Hn3cQoJHoW-CSUSGD9xuNehoA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJwKpyTmYjnJs%3DJHzRVW9Ln_gQc1zZffNsv%2BRf7u0o0YmHBnsg%40mail.gmail.com.
