avocado
avocado copied to clipboard
chop-dbhi
Django 1.8 support
Coverage increased (+0.1%) to 80.353% when pulling cc5f36dbab67067859886f24b20357b76b1d1db9 on sgithens:django-1.8-support into c081e31e494093cb8608fb771166082bb3638fa2 on chop-dbhi:master.
@sgithens It appears the the other Django versions are not actually being tested. 
The reason this is happening is because you put a hard version in requirements.txt. Can you change this back to a range django>=1.5,<1.9 and update setup.py to the same range.
I am sure there will be an issue with 1.5 and it may be time to drop support for it, but I would like the tests to tell us that. Thanks!
Coverage increased (+0.1%) to 80.353% when pulling 7b26d3738dae200a63a4c09aac40481081fed01a on sgithens:django-1.8-support into c081e31e494093cb8608fb771166082bb3638fa2 on chop-dbhi:master.
@bruth Updated, and all the builds except 1.8 failed. :)
I wonder if maybe we should explore including post 1.8 versions to get a heads up on what issues we might encounter going forward.
Coverage increased (+0.1%) to 80.353% when pulling 284c7a63913b339fd86616e663eb41eefe31add3 on sgithens:django-1.8-support into c081e31e494093cb8608fb771166082bb3638fa2 on chop-dbhi:master.
@sgithens From the Travis errors, 1.5 and 1.6 are failing because South is not installed. 1.7 is failing because modeltree 2.0.0 is being used and it should be 1.1.10 since 2.0.0 is 1.8 only (this is true for Django 1.5 and 1.6).
Django 1.9 and 1.10 are failing due to a failed import presumably because it was deprecated in an earlier release.
ValueError: Unable to configure handler 'null': Cannot resolve 'django.utils.log.NullHandler': No module named NullHandler
On the call today, I think it is worth getting feedback on whether we should just cut over to 1.8+ for future development. We can increment new releases under the 3.x series to denote this change.
Coverage increased (+0.1%) to 80.353% when pulling 0d1bf829f9e4fc030f26c0cf8df2b4b02acacf15 on sgithens:django-1.8-support into c081e31e494093cb8608fb771166082bb3638fa2 on chop-dbhi:master.
Coverage increased (+0.4%) to 80.647% when pulling 59da86f2204cf109f972dd385f429acf9cc5ce89 on sgithens:django-1.8-support into c081e31e494093cb8608fb771166082bb3638fa2 on chop-dbhi:master.
Looking at the travis output from this, and also from previous travis builds before the 1.8 work... it looks like travis was always only running the tests on sqlite, even if it was also creating the postgres and mysql databases. Unless I'm reading things wrong. Looking at making the test running run the actual tests against all the enabled databases, as well as 20 errors/failures that have appeared after I actually enabled MySQL locally.
Coverage increased (+0.4%) to 80.592% when pulling d020165196040a279c180478a55059adaebffbb9 on sgithens:django-1.8-support into c081e31e494093cb8608fb771166082bb3638fa2 on chop-dbhi:master.
Finished fixing most of the MySQL issues, 2 fails and an error to go, and then fixing up the travis config to make sure it actually runs them on mysql/postgres in addition to sqlite.
Coverage increased (+0.07%) to 80.274% when pulling 3d5f4ad7ee6aba9ae85c764bb28314bcaacd19b5 on sgithens:django-1.8-support into c081e31e494093cb8608fb771166082bb3638fa2 on chop-dbhi:master.