On Sun, Jan 1, 2023 at 12:54 PM Tim Graham <timogra...@gmail.com> wrote: > Older Django releases are currently maintained with minimal support that > allows existing projects to continue running securely. I don't think we > should invest resources in promoting them as a place to use experimental > features. A benefit of running an old LTS release like 3.2 is that any > release at this point is probably a very important upgrade (security or data > loss issue). If we start making new LTS bug fix releases to fix experimental > features, releases may be more frequent and less important. Of course, with > more changes, the risk of unrelated regressions increases, including the > possible bad situation in which users put off a bug fix upgrade because it > doesn't have any security fixes only to face issues updating to a subsequent > security release because of an issue in an interim bug fix release. (Maybe > mergers can estimate how many other async fixes would be eligible for a > backport based on the proposed criteria.)
The backport policy already says that Django will backport certain things into older releases. I do not agree with your assessment of the risk of backporting, but even if we grant it for sake of argument, the Django project overall has already clearly endorsed -- through the current backport policy -- the idea that some fixes are important enough to override such concerns and to backport even into releases that are on "minimal" support. I happen to think that this is one such fix, for reasons that I have laid out at length. I also think the backport policy should be amended to prevent an issue like this from "slipping through the cracks" again in the future. I am still considering the wording Shai proposed, though on first read I thought it was getting at the right idea. > James argues that this bug that went unreported for 2+ years is now very > important and is going to cause massive pain for many users. Only time will > answer this, but I'm skeptical. So far I believe we've seen two people > affected, James and the ticket reporter. Well. I had been trying to avoid bringing this up because I felt that the backport policy and the severity of the bug were the things to focus on, and because I was trying to avoid singling out individual mistakes that contributed to the situation we have now. But there is at least one other report of this bug in the Django Trac instance. It is the first one I found when trying to diagnose the problem in my own code (and the one I mentioned in my initial question on IRC, as anyone who saw that can confirm), and it is one that was filed only a couple of months after the release of Django 3.1, so well within the window of time when the backport policy would have said to apply the fix to the 3.1 branch as well as to main. It also correctly diagnosed the source of the bug and provided an attempt at a patch. That ticket was #32189: https://code.djangoproject.com/ticket/32189 But it was closed invalid as a user error. We can debate whether the user should have been trying to access request.POST for their particular use case, but we cannot debate whether this is the underlying bug that user was encountering. It also was clearly not the normal behavior one ought to see from accessing request.POST, even in a non-POST request or supposedly non-appropriate context, and likely either should not have been closed, or should have produced a follow-up ticket to investigate why that specific behavior was occurring. As for whether anyone else is affected: my searching turned up several references on other sites to the exact error message the bug produces, which all seemed to receive replies along the lines of #32189: that it was the fault of the reporter for accessing request.POST rather than request.body. So. I have said several times that using a strict reading of the backport policy to avoid fixing a severe bug sends a bad message. I will amend that now, and say that using a strict reading of the backport policy to avoid fixing a bug, when the bug was reported to Django within a window where the backport policy should not have mattered, sends an even worse message. I also do think that more people will trip over this bug as they start using async Django, and that leaving it unfixed creates a problem of how to communicate the need for a workaround without violating a strict reading of the backport policy. > This bug will be a non-issue for third-party apps with the release of Django > 5.0 in December if they follow the suggested Django version support policy: I have repeatedly pointed out that I do not think Django should force the choice of long-delayed async adoption, or fracturing of the community, onto maintainers of third-party packages and libraries. My objection was to waiting until Django 3.2 drops out of support, which is in April 2024, but the objection would apply equally to saying that a feature released in 2020 must be left in a state where it is not reliably usable until December 2023. > Until then, apps could run the affected tests only on Django 4.2 (which will > have an alpha release in about two weeks) if they don't want to work around > the bug. I still maintain that this is extremely poor developer experience, and sends an extremely bad message about Django and its commitment to reliability and stability. At the moment, there are zero officially-supported releases of Django one can install that have a working AsyncClient, despite AsyncClient being a documented and allegedly supported API since August of 2020. Under my proposal, developers would not have to wait for a future feature release just to have the first actually-working AsyncClient, and developers of third-party packages and libraries would not have to resort to workaround, or delay async adoption, or fracture their usual support matrices to deal with the bug. So I return again to my contention that an exception ought to be made to the backport policy, and that the fix should be backported to all currently-supported Django release series: 4.1, 4.0, and 3.2 LTS. -- 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/CAL13Cg9TOrFZz1MFhP-tA-5bBvT0eKxaBupRTitStBv_SWnytg%40mail.gmail.com.
