3.15 Release #9210
3.15 Release #9210
Conversation
- Add docs/community/3.15-announcement.md - Update docs/community/release-notes.md - Update mkdocs.yml Co-authored-by: Bruno Alla <[email protected]>
…ework into math-a3k-315_rn
Co-authored-by: Christian Clauss <[email protected]>
|
Anything else blocking us from merging this? |
|
Should this milestone be resolved and merged? |
Not sure if a blocker, but you might want to update that sentence with -at least- an updated date:
|
Okay, someone want to propose a release date and make a +/- suggestion? |
|
This is the final step to release, right? If so, the sooner the better, but I think you'll want to review your release process and set your own time to release. |
|
Okay, I'd suggest March 15th... perhaps someone could issue a +/- suggestion and we plan on making the release then? |
Co-authored-by: JAEGYUN JUNG <[email protected]>
docs/community/release-notes.md
Outdated
| * Fixes `BrowsableAPIRenderer` for usage with `ListSerializer`. [[#7530](https://github.com/encode/django-rest-framework/pull/7530)] | ||
| * Change semantic of `OR` of two permission classes [[#7522](https://github.com/encode/django-rest-framework/pull/7522)] | ||
| * Remove dependency on `pytz` [[#8984](https://github.com/encode/django-rest-framework/pull/8984)] | ||
| * Fix validation for ListSerializer [[#8979](https://github.com/encode/django-rest-framework/pull/8979)] |
There was a problem hiding this comment.
#8979 is marked as "breaking change" and the fix for that (#9244) is not merged yet. It should be noted in the release notes this is a breaking-change.
@TGoddessana please see same implemented @, thank you,
There was a problem hiding this comment.
Although I'm not a maintainer, I'm very interested in the maintenance of the project, so I took a look at the issues.
-
one PR (Fix validation for ListSerializer #8979) that solves the original issue (Invalid
self.instancewhen validating the serializer usingmany=True#8926) seems to have been merged already, but the better implementation (Improve ListSerializer #9244) is still not fully resolved based on the last comment in the issue. -
so which decision do we make?
- Should we revert Invalid
self.instancewhen validating the serializer usingmany=True#8926 if we need a better implementation? If a better design exists, would it be a good decision to include it in the 3.15 release? - Do we need to rush Improve ListSerializer #9244 to completion? Can we get it done before the release?
- Maybe we could revert Invalid
self.instancewhen validating the serializer usingmany=True#8926 and ship a bugfix release with 3.15.1 with a better implementation? It was clearly labeled as a breaking change, but it felt more like a bug fix to me.
Would love to hear your thoughts @tomchristie 🥲
There was a problem hiding this comment.
IMO the problem is that #8926 was addressed ignoring the advice regarding "Customizing multiple update"
By default the
ListSerializerclass does not support multiple updates. This is because the behavior that should be expected for insertions and deletions is ambiguous.To support multiple updates you'll need to do so explicitly. When writing your multiple update code make sure to keep the following in mind:
- How do you determine which instance should be updated for each item in the list of data?
- How should insertions be handled? Are they invalid, or do they create new objects?
- How should removals be handled? Do they imply object deletion, or removing a relationship? Should they be silently ignored, or are they invalid?
- How should ordering be handled? Does changing the position of two items imply any state change or is it ignored?
You will need to add an explicit id field to the instance serializer. The default implicitly-generated id field is marked as read_only. This causes it to be removed on updates. Once you declare it explicitly, it will be available in the list serializer's update method.
Thus the proposed solution (#8979) only addesses a single use case while ignoring out many others which are now not supported by the framework. For example: using ListSerializer to perform in a bulk request a "create-update-delete" of a list of objects which was possible before this change.
PS: there is also an issue with the current implementation of ListSerializer when validating instances and just use "index" to choose which instance will be associated to which data.
There was a problem hiding this comment.
I was thinking about reverting that for this release
There was a problem hiding this comment.
#9283 let me know your thoughts, and we can wait for a better fix in future
There was a problem hiding this comment.
If this change is not released in 3.15, which release do you think is the right one to fix and release it in: 3.16 or 3.15.1?
There was a problem hiding this comment.
if it is just reverted it will not be included in 3.15, as it is a big thing, it should be included in a major release like 3.16/3.17
There was a problem hiding this comment.
I just want to avoid including any not fully functional feature for 3.15
There was a problem hiding this comment.
I just want to avoid including any not fully functional feature for 3.15
I agree with you. Thank you for your efforts!
Co-authored-by: JAEGYUN JUNG <[email protected]>
|
Okay, I think we're good to release here? |
|
Okay, I might have enough time to roll this release later today... (on schedule |
|
https://docs.djangoproject.com/en/stable/faq/install/#what-python-version-can-i-use-with-django still supports Django 3.2 (at least until next month). However, I think we could safely drop support for Python < 3.8 (https://devguide.python.org/versions) because supporting five different versions of CPython is enough effort. Perhaps release this as is and then in a few months create a release that drops Django v3.x and also Python < 3.8. |
|
Okay, we're merged add ready to publish. |
|
Thank you guys for pushing this out the door. Much appreciated! Now that the pypi release is done, we should probably also craft a github release for 3.15.0. |
Reviewing #8794.
Starting point, I've reviewed the release notes, and cleaned up items that shouldn't be included...
Our release notes should reflect changes to the released package version.
So... behavioural changes that users may need to be aware of.
Project documentation, workflow, and testing isn't part of that and shouldn't be part of our release notes.