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.)
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. 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: "Following the release of Django 5.0, we suggest that third-party app authors drop support for all versions of Django prior to 4.2. At that time, you should be able to run your package’s tests using python -Wd so that deprecation warnings appear. After making the deprecation warning fixes, your app should be compatible with Django 5.0." 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. On Sunday, January 1, 2023 at 10:21:48 AM UTC-5 Shai Berger wrote: > Hi, > > I think at this point it would help to move the discussion forward, if > we tried to step beyond the specific issue and phrase the revision in > the backporting policy. This will let us, I hope, have a more > principle-based discussion. > > If I get it right -- please correct me, James -- it would be something > like this addition: > > "In a new domain of functionality, which is considered major and > central, bugs which would have been release blockers if found in time > will be considered as candidates for backporting if found within the > next two LTS versions" -- or even "... if found before use of the new > domain of functionality becomes mainstream" -- or something similar. > > I think looking at it from that angle will be more fruitful. I will say > that looking at this principle, thinking about the vicious cycle > mentioned by James, I tend towards accepting his arguments. > > We may want to phrase it a different way: Think of such major domains > as "experimental". We did that in the Python3 transition -- we had > "experimental support" from 1.5, and IIRC that "experimental" label > wasn't dropped until 1.8. I doubt we can retroactively declare async > views as still experimental, but we can modify the backporting policy > to say "release-blocker-level bugs in experimental features will be > candidates for backporting as long as the feature is experimental"; > and we can set an exception that says "async is still experimental for > backporting considerations", in view of the little use we've seen so > far. > > (I can see the argument against the last proposition, that says > "experimental means potentially broken, so it should be less worthy of > backports rather than more"; I disagree, because (a) we do want to > encourage such experimentation, and (b) no, it doesn't really mean > potentially broken, it means the API is not yet covered by the > stability guarantees; we're at more liberty to change things when we > fix) > > HTH, > Shai. > -- 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/35bad7b0-1811-4a1e-a396-bd8e6591699fn%40googlegroups.com.
