-
-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Django up to 1.11, fix DeprecationWarnings, fixes #89 #104
Support Django up to 1.11, fix DeprecationWarnings, fixes #89 #104
Conversation
Also set warnings to raise as errors in unit tests to prevent regressions that re-introduce the warnings.
This pull request is a big clean up of the codebase. I hope this can be merged soon. I would also love to implement the solution I just suggested in #102 (comment). I also agree supporting django >= 1.8 would be enough for the current use case. |
Any timeline on this? Just tried updating a Django project from 1.8 to 1.10 and saw an extremely large increase in deprecation warnings (mostly from this package.) I'm also happy to submit a smaller pull request directly addressing my issue Also agree that at this point, supporting >=1.8 is a pretty reasonable choice, but I also think keeping backwards compatibility is an awesome feature of this package. |
@gregmuellegger I also would like to see this merged. Let us know! |
@gregmuellegger I would like to see it merged, too. |
There are too many DeprecationWarnings, revert when jazzband/django-sortedm2m#104 lands
There are too many DeprecationWarnings, revert when jazzband/django-sortedm2m#104 lands
There are too many DeprecationWarnings, revert when jazzband/django-sortedm2m#104 lands
There are too many DeprecationWarnings, revert when jazzband/django-sortedm2m#104 lands
There are too many DeprecationWarnings, revert when jazzband/django-sortedm2m#104 lands
There are too many DeprecationWarnings, revert when jazzband/django-sortedm2m#104 lands
There are too many DeprecationWarnings, revert when jazzband/django-sortedm2m#104 lands
@gregmuellegger any updates on when it will get merge? |
@gregmuellegger |
@gregmuellegger Thanks for your work on this library! We use it as well, and need it to work with django 1.11. Is there anyone else who has commit privileges on this repo, or anyone you could add? That would let these changes move forward, and could make the burden lighter for you. |
@gregmuellegger I'm also willing to help out since openwisp2 uses this django app as a dependency. |
As workaround, you can do |
1.4.0 is out containing these changes! https://pypi.python.org/pypi/django-sortedm2m Sorry for the very long wait! I'm super super occupied currently in my private live which sets open source a little on the back burner currently. I will try to find a better maintaining solution for the long run. For now, thank you everyone for being so patient and very constructive in your comments and contributions! I'm would appreciate any positive feedback about if sortedm2m now works for you as expected with Django 1.11. |
With the caveat that I'm still in the midst of (belatedly) writing unit tests for my Django apps: from a manual exercise of the website and checking the warning logs, this got rid of all of the sortedm2m-related deprecation warnings, and everything seems to be operating properly. |
* Support Django up to 1.11, fix DeprecationWarnings Also set warnings to raise as errors in unit tests to prevent regressions that re-introduce the warnings. * Renamed duplicated TestStringReference classes jazzband#105 Fixes jazzband#105 * Add changelog for 1.4.0 release * Bump version to 1.4.0 * Prepare new dev version * Adding missing link to jazzband#104 in changelog * Fixes jazzband#96: Improve string representation of sortedm2m relationships
I've also set warnings to raise as errors in unit tests to prevent DeprecationWarnings from being reintroduced accidentally in future.
I've added the intermediate django versions to tox.ini and to the travis build matrix. I've also added
py36-master
to the build matrix, though marked as an allowed failure so that it can fail without affecting whether the build as a whole passes. I've made it so that the tests pass against the django master branch (2.0), so it currently passes on travis, but since it's under development it's possible that there could be an upstream change that might breaks things.(As an aside, keeping django support going back to 1.5 is laudable, but I don't think anyone would hold it against you if you only supported Django >= 1.8).