models.DateField => graphene Date Scalar

[urbandove]

Currently models.DateField is processed as a DateTime Scalar - this changes it to the new Date Scalar added to graphene

Please note - that the test pass on Django 1.11 - but i was having erros crop up on django 2.0 (1 related to pytest dependancy and the rest was an issue of foreignkeys missing the rel attribute - which i dont think is caused by this)

[coveralls]

Coverage decreased (-0.6%) to 92.559% when pulling 62c0694 on urbandove:master into 24706f5 on graphql-python:master.

[coveralls]

Coverage decreased (-0.6%) to 92.559% when pulling 62c0694 on urbandove:master into 24706f5 on graphql-python:master.

[coveralls]

Coverage decreased (-0.6%) to 92.559% when pulling 62c0694 on urbandove:master into 24706f5 on graphql-python:master.

[coveralls]

Coverage decreased (-0.2%) to 92.966% when pulling 48ae9f0 on urbandove:master into 24706f5 on graphql-python:master.

[coveralls]

Coverage increased (+0.03%) to 93.17% when pulling 62c0694 on urbandove:master into b54e02c on graphql-python:master.

[coveralls]

Coverage increased (+0.03%) to 93.17% when pulling 7f8877f on urbandove:master into b54e02c on graphql-python:master.

[coveralls]

Coverage increased (+1.08%) to 94.227% when pulling da3bb5e on urbandove:master into b54e02c on graphql-python:master.

[spockNinja]

Thanks for the PR!

The change to use Date instead of DateTime makes a lot of sense now that upstream Graphene has added that type.

There is a separate PR handling the change to support Django 2.0 in tests (#336). So if you could slim this PR down to just the Date changes, that would be great.

Then, since this will cause a change in existing behavior, we need to make sure it goes behind a version bump.

[urbandove]

Hi @spockNinja
Thanks for looking this over.
I've removed the code for the django 2 updates to keep this pull request cleaner - it was left in my branch from #336 by mistake
I've also added a version bump to 2.0.1 - same as the version of graphene which supports Date Scalars

[spockNinja]

Thanks @urbandove!

@syrusakbary This update looks good to me. I'm not too sure how you want to handle version bumps when something breaks existing functionality (but is still a general improvement). @urbandove has bumped the version in this PR, but if that's not the version workflow you follow, we can undo that. In my review, I was just making a note of the need for a bump in general (before it goes to pypi), not necessarily in this PR.