Cut a release compatible with Django 1.11

[adamzap]

Any chance we could get an official release since #1480 was merged?

Thanks!

[georgedorn]

I wasn't sure I had the ability to publish to PyPI, but evidently I do now. I'll have a look later this week to see what PRs can be merged and then cut a release for 1.10.

@adamzap If you feel like helping, you could have a look at open PRs and comment on those that seem possible to include in the release. If you don't have time, that's fine, but if you do that'd speed things up a bit.

[adamzap]

Sure! I took a look at all PRs assigned to the v0.13.4 milestone, and unfortunately, they are all waiting of follow up from the person that opened them (merge conflicts, needs tests, etc). I could open new PRs for some of them if they seem worthwhile.

However, I think #1485 can be merged immediately since it's a simple documentation fix, and #1320 can be closed since it includes no changes.

Let me know what you think. I'll keep looking around.

Are you on IRC somewhere? Maybe we can chat about how I can be more helpful.

Also, thanks to my employer, Crossway, for allowing me to spend work time on this!

[SeanHayes]

The milestones are pretty much meaningless, I assigned issues to them as a way of prioritizing them for myself, but I haven't had time to work on those releases. Generally speaking, 0.13.4 issues should be done before 0.14.0 issues and are less likely to break backwards compatibility, so they should still be kept separate. The 1.0.0 milestone was there before I joined, some of them maybe should be moved up in priority.

[adamzap]

Ah ok. 90 of the 122 open PRs have merge conflicts. I'm not sure what you want to do about those. For what it's worth, Django's maintainer asks for follow-up, waits for a period of time, and closes the request if the author doesn't respond.

Here are the remaining 32 PRs with some assessment from me:

• Fixes issue #96 - Changed the OneToManyField #236 (Not finished)
• Fields with null=True should dehydrate to None before returning the default #271 (Seems ready, needs release note)
• updated example of nested resources by lightly overriding the override_urls method & adding on a new method to handle the children #320 (Documentation fix, seems ready)
• Modifying Error Handling of ModelResource.obj_get() #379 (Design decision needed)
• Problem with ForeignKey form validation. #540 (Buggy implementation)
• [bugfix] Fixes m2m PUT #575 (Further changes needed?)
• Improve cookbook 'Adding Search Functionality' #662 (Documentation fix, needs review)
• Moved X-HTTP-Method-Override into method_check in order to support custom methods #695 (Needs tests)
• Add BigIntegerField to the Django model types supported for IntegerField... #761 (Seems ready)
• Docs: improved Reverse Relations, added related_name note #798 (Documentation fix, needs review)
• Add test for #327 #834 (Adds a single test, seems ready)
• Update to Allow CleanedDataFormValidation to work with forms/models that have related fields. #923 (Needs review)
• Test client sets wrong content type if request doesn't specify content type, closes #988 #989 (Needs fix and tests)
• Added method to get all instances of Api versions. #1014 (Needs review and design decision)
• Fix to save something but always update the related fields. #1127 (Tests fail)
• Do not send 404 exceptions via got_request_exception #1166 (Needs more comprehensive fix)
• Provide mixins for easier subclassing and combining #1192 (Seems ready)
• Included a new HttpResponse class: HttpPaymentRequired #1195 (Tests fail, need test)
• Resource.save_m2m travels double-underscore relations #1242 (Needs test)
• Force attribute name to be string in Exception #1256 (Patch needs improvement and test)
• Provide use_in value to the use_in field callback #1265 (Needs follow-up from maintainer)
• opportunity make Resource with crossing name of resource_name and differ... #1279 (Needs test)
• Add some debug messages to certain cases. #1320 (No diff)
• Add custom_api decorator which helps to implement non-CRUD end point #1321 (Design decision needed)
• Updated Api class to build correct URLs even when api_name contains s… #1453 (Needs test)
• Unquote url-s containing escaped characters #1457 (Needs test)
• Update to Allow CleanedDataFormValidation to work with forms/models that have related fields. #1463 (Needs follow-up from maintainer)
• Advanced Filtering example missed ignore_bad_filters paramter #1469 (Documentation fix, needs review)
• Fixed bug in ToOneFields when attribute is not a string #1482 (Seems ready, might need review)
• removed slumber.in reference #1483 (Patch needs improvement)
• Correct 404 status text to "Not Found" #1485 (Documentation fix, seems ready)
• Fix warnings #1486 (Seems ready, needs further review)

I hope this is helpful!

I personally think Django 1.10 compatibility is enough for a release, but it's up to yall!

[SeanHayes]

I'd like to do the same and just close them due to inactivity, but a lot of them are for legitimate bugs so we need to keep a record of them.

[ghost]

Any news?

[Nijhazer]

Following up on this.

[ssjunior]

Following.

[john-clarke]

Following.

[aehlke]

Please just hit the "Subscribe" button to follow this thread. If you comment, you notify everyone else that you're subscribing. We're all interested :)

[gediminas-revel]

Any plans to support Django 1.11?

https://www.djangoproject.com/weblog/2017/apr/04/django-111-released/

[aehlke]

It seems there are Django 1.10 compatibility fixes that landed in master. It would help if someone could confirm whether tastypie master branch has issues with 1.11.

[cristianocca]

What's the status on this? Thanks.

[hello-alf]

in Django 1.11 we have problems too, please update compatibility for django 1.11

[georgedorn]

TODO:

Release notes:

• Add note about preferring nulls to defaults when null=True and current value is None (Fields with null=True should dehydrate to None before returning the default #271)
• Update documentation about supported versions (1.8, 1.11, python 2.7 and 3.?)

Tests:

• Add python 3.6 to tox/travis test matrix.
• Consider using a fork of django-oauth-plus / django-oauth-provider that supports django 1.11 during tests. Not sure whether to add this suggestion in our documentation.

Fixes left to do:

• Silence a huge number of warnings. Fix warnings #1486 might be a good place to start, but new ones exist under 1.11 regarding django 2.0. I'm not sure how to best get all of these, as we appear to be silencing warnings during unit tests.

[mattbriancon]

@georgedorn I'm happy to rebase #1486 or do whatever else needs doing to get things moving again.

[sp1rs]

Is tastypie supporting Django 1.11?

[georgedorn]

Release v0.14.0 was just uploaded to PyPI. It includes explicit support for LTS versions of Django (1.8 and 1.11). Django 1.9 and 1.10 almost certainly are compatible, but are unsupported.