James, I think the backport policy has proven itself over the years, no?
"Django lied" — that's a bit melodramatic don't you think?. Django introduced a new feature, as it is wont to do. There was a bug in that new feature, as there are wont to be. Unfortunately that bug was not discovered during the timeframe in which it would qualify for a backport. However it's fixed in the upcoming version, which will be in pre-release in just a couple of weeks. Sorry for the inconvenience, but backport and supported versions policy is the foundation of the stability and ease of update you've come to appreciate in Django over all these years. > This is a showstopper of a bug... 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. > Unless another major bug gets found... I'm *quite certain* there are plenty more of these to be found. The journey is still really only just beginning. I'd guess I'd say we're entering a new phase, but the async support is neither complete nor mature. There will be bugs. I'm -1 on making an exception to the backport policy in this case. (Sorry I don't agree with you.) Kind Regards, Carlton On Fri, 30 Dec 2022 at 10:38, James Bennett <ubernost...@gmail.com> wrote: > On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson <carlton.gib...@gmail.com> > wrote: > > It's frustrating when this happens, but the backport policy has proven > its worth time and again. > > I **really** don't see the case for making an exception here. > > (The policy has more value than the inconvenience in any of these cases, > or even all of them summed.) > > I don't see the value here. > > If it's left as-is, the message is, effectively, that Django lied > about its async support for years, but suddenly *now* is asking people > to trust the claims of async support. Unless another major bug gets > found, in which case "well, *now* you can trust Django on async" will > get kicked down the road again. > > This is a showstopper of a bug, and just leaving it deliberately > unfixed in *every released version of Django* because "policy said no" > has the potential to do a lot of damage to Django's reputation. > > > Adding the support here is difficult and slow enough. Backporting fixes > to discovered bugs, outside the established policy, is making an > unrealistic burden for ourselves. > > I'm not saying every bug found with async needs a backport. But one > that literally prevents the built-in testing tool from working with a > huge swathe of views and middlewares (including potentially some built > in to Django itself), *when that tool is documented and Django claims > to officially support it*, is just unacceptable. I'll work up the > patches myself if that's what it takes. > > -- > 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-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%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/CAJwKpyQdcKve7rx2fwscf-WTY5c2SzgtaCJeOC66hAbTiMd3dw%40mail.gmail.com.
