Allowed Travis failures for Django master.

[timgraham]

Support for Django 2.0 will be added upon its release (while dropping support for Django < 1.11).

[timgraham]

I couldn't figure out how to make allowed_failures work here -- I think removing it is fine given there will be no change in the failure status until Django 2.0 support is added.

[claudep]

Are you sure it's not possible? I'd like to keep master testing with allowed_failures if possible.

[timgraham]

No, I'm not sure. I don't know tox/Travis very well.

[claudep]

Me neither, so don't rush and let's try to find some knowledgeable fellow.

[timgraham]

I'm curious to hear about the advantage you see of running those builds?

[claudep]

I think it's a good practice to promote in third-party apps. It allows to detect soon either deprecated stuff usage (which is the case with this package) or unplanned incompatibilities currently in Django master.

[timgraham]

I agree but at this time in Django's development cycle, we can't fix the failures until we drop support for Django < 1.11 (unless adding conditional fixes for the Django deprecations which the new Django release cycle was intended to avoid). I think the time to do that would be around Django 2.0 alpha, so I don't see a need for the builds in the meantime.

[claudep]

In my practice with third-party reusable apps, I strive to make them deprecation warning free with all supported versions. In my own apps (non-reusable), I regularly activate deprecation warnings to see if the code is entirely up-to-date, and reading tons of warnings from third-party apps is not nice when doing this.

[timgraham]

Then we aren't in agreement to follow https://docs.djangoproject.com/en/dev/releases/1.11/#deprecating-warnings-are-no-longer-loud-by-default?

[claudep]

That's right, I don't totally agree. The suggested strategy is nice for LTS to LTS jumps, but not for those who are following each version of Django. I'm practicing the latest in all of my projects, and when I have the time and money to do it, I'm also trying to keep my projects deprecation-free even with Django 1.9 or Django 1.10. For actively-maintained (and well-tested) projects, I found that's a successful practice, because it distributes the upgrading work instead of "big" LTS upgrades.

[charettes]

I couldn't figure out how to make allowed_failures work here.

Did you try

matrix:
  allow_failures:
    - env: TOXENV=py34-django-master
    - env: TOXENV=py35-django-master

[timgraham]

Thanks Simon. I missed the matrix: part.