Consider withdrawing release 3.15.0

[peterthomassen]

Given the various serious regressions discovered so far (~10?), and given that more are being discovered, I've become concerned whether installing a 3.15 release is safe, even when the issues listed in #9331 are addressed in 3.15.1.

With several users having expressed serious concern (e.g. #9306 (comment)), it seems like in order to avoid further erosion of confidence in the project, the best thing to do may be to withdraw the broken release, and instead carefully prepare a 3.16 release while ensuring to retain the quality standards that this project has been known for.

Thank you for considering!

I'm tagging a few random people from issues and discussions who seemed to be concerned, in case they'd like to add something. @mrzorn @kevinrenskers @henribru @joseph2rs @alexdlaird @Mehourka @shammellee @martinlehoux

[kevinrenskers]

100% agreed. People should not install 3.15.0 considering all the issues, and considering that most changes are being undone.

[mrzorn]

As mentioned in the comment you linked to, I did fix the known issues in my code base(s) with 3.15 but am still strongly considering reverting back to 3.14 which I have been using without issue since it was released.

Are there any "must have" updates in 3.15 that are required for django 5? In my experience, it was all working as expected - I have been running Django 5 in prod since shortly after its release.

Withdrawing 3.15, adding a subset of what was in it to a 3.16, especially as it relates to both Django 5 and any security issues, and shoring up test coverage to help ensure that breaking changes do not occur in the future seems like a smart move to me.

[tomchristie]

Withdrawing 3.15, adding a subset of what was in it to a 3.16, especially as it relates to both Django 5 and any security issues, and shoring up test coverage to help ensure that breaking changes do not occur in the future seems like a smart move to me.

I'd be in favor of this yep. We should really only be tracking Django changes and handling security issues.

Was a bit concerned about the number of changes in this release, but we've not had anyone pushing back on it or vocalizing concerns. Evidently we need to put in place some strict contribution constraints, and ensure that the project is under properly resourced leadership.

I've been working on getting a 3.15.1 patch out, but right now it's late, I'm exhausted, and need to sleep for a few hours before getting this tidied up.

[tomchristie]

Okay, having had the time to sit down with this today, I think we've got a sensible patch release... #9339

Let's start by getting that out the door.

[tomchristie]

Okay, we do now have a 3.15.1 release patching the various issues raised.

[alexdlaird]

I'll add one more example to the mix here form my experience, if for no other reasons so if others search for this issue they find the reason / my solution.

I continue to pin back 3.14.0, because even though 3.15.1 does fix my build issue, several of my tests still fail. Namely, I have tests that assert on a 404, and I include in that assertion the response body. I used to assert that not found was in the body. I personally consider this a brittle test, but I can't guarantee my downstreams don't, and as an API provider, I need to be overly cautious.

In 3.15.0, the NotFound response body changed. I would consider this a breaking change, because the contract of the API—in this case the formatting of the response—has changed. Someone else brought up the issue of test coverage, but what concerns me is actually that djangorestframework does appear to have pretty good coverage. But the test that would have caught this was changed to fit the new format without calling it out as needing a major version bump:

Asserted test in 3.14.0:

django-rest-framework/tests/test_generics.py

Line 522 in 2da473c

assert response.data == {'detail': 'Not found.'}

Asserted test in 3.15.0:

django-rest-framework/tests/test_generics.py

Line 527 in 2d8e9ad

string='No BasicModel matches the given query.',

This change is referenced in the release notes, but not in a way that I'd understand it to be a breaking change. This PR is referenced for the change. If I didn't have my own 404 test wrapped around this (as I imagine many wouldn't), I would have released what I consider a breaking change to my downstreams without a major version bump.

Now this response body actually comes from Django itself: https://github.com/django/django/blob/a76c52b19a221147f3a903848f711daa367e2e20/django/shortcuts.py#L88

But DRF didn't seem to be passing it through before, so while I agree that it's better to pass on Django's response body here for a 404, the fact that DRF changed its own implementation (the exception info from Django kwargs started being passed to NotFound in 3.15.0 in views.py where it wasn't before) of how it does that would still be considered a breaking change to me.

---

For those that find this discussion trying to find how to change this behavior back to how it was, set a customer exception handler:

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler'
}

Here is a simple implementation:

from rest_framework import status
from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):
    # Call REST framework's default exception handler first,
    # to get the standard error response.
    response = exception_handler(exc, context)

    # Now add the HTTP status code to the response.
    if response is not None and response.status_code == status.HTTP_404_NOT_FOUND:
        response.data['detail'] = 'Not found.'

    return response

[nicwolff]

We too have had to pin 3.14.0 because 3.15.1 doesn't fix a test that 3.15.0 broke.