Release Notes

(From: https://docs.djangoproject.com/en/1.11/releases/1.11/)

Welcome to Django 1.11!

These release notes cover the new features, as well as some backwards incompatible changes you’ll want to be aware of when upgrading from Django 1.10 or older versions. We’ve begun the deprecation process for some features.

See the Upgrading Django to a newer version guide if you’re updating an existing project.

Django 1.11 is designated as a long-term support release. It will receive security updates for at least three years after its release. Support for the previous LTS, Django 1.8, will end in April 2018.

Python compatibility

Django 1.11 requires Python 2.7, 3.4, 3.5, or 3.6. Django 1.11 is the first release to support Python 3.6. We highly recommend and only officially support the latest release of each series.

The Django 1.11.x series is the last to support Python 2. The next major release, Django 2.0, will only support Python 3.5+.

Deprecating warnings are no longer loud by default

Unlike older versions of Django, Django’s own deprecation warnings are no longer displayed by default. This is consistent with Python’s default behavior.

This change allows third-party apps to support both Django 1.11 LTS and Django 1.8 LTS without having to add code to avoid deprecation warnings.

Following the release of Django 2.0, we suggest that third-party app authors drop support for all versions of Django prior to 1.11. At that time, you should be able run your package’s tests using python -Wd so that deprecation warnings do appear. After making the deprecation warning fixes, your app should be compatible with Django 2.0.

What’s new in Django 1.11

Class-based model indexes

The new django.db.models.indexes module contains classes which ease creating database indexes. Indexes are added to models using the Meta.indexes option.

The Index class creates a b-tree index, as if you used db_index on the model field or index_together on the model Meta class. It can be subclassed to support different index types, such as GinIndex. It also allows defining the order (ASC/DESC) for the columns of the index.

Template-based widget rendering

To ease customizing widgets, form widget rendering is now done using the template system rather than in Python. See The form rendering API.

You may need to adjust any custom widgets that you’ve written for a few backwards incompatible changes.

Subquery expressions

The new Subquery and Exists database expressions allow creating explicit subqueries. Subqueries may refer to fields from the outer queryset using the OuterRef class.

Minor features


django.contrib.admin


django.contrib.auth


django.contrib.contenttypes


django.contrib.gis


django.contrib.postgres


Cache


CSRF


Database backends


Email


File Storage


Forms


Internationalization


Management Commands


Migrations


Models


Requests and Responses


Serialization


Templates


Tests


Validators

Backwards incompatible changes in 1.11


django.contrib.gis


django.contrib.staticfiles


Database backend API

Dropped support for PostgreSQL 9.2 and PostGIS 2.0

Upstream support for PostgreSQL 9.2 ends in September 2017. As a consequence, Django 1.11 sets PostgreSQL 9.3 as the minimum version it officially supports.

Support for PostGIS 2.0 is also removed as PostgreSQL 9.2 is the last version to support it.

Also, the minimum supported version of psycopg2 is increased from 2.4.5 to 2.5.4.

LiveServerTestCase binds to port zero

Rather than taking a port range and iterating to find a free port, LiveServerTestCase binds to port zero and relies on the operating system to assign a free port. The DJANGO_LIVE_TEST_SERVER_ADDRESS environment variable is no longer used, and as it’s also no longer used, the manage.py test --liveserver option is removed.

If you need to bind LiveServerTestCase to a specific port, use the port attribute added in Django 1.11.2.

Protection against insecure redirects in django.contrib.auth and i18n views

LoginView, LogoutView (and the deprecated function-based equivalents), and set_language() protect users from being redirected to non-HTTPS next URLs when the app is running over HTTPS.

QuerySet.get_or_create() and update_or_create() validate arguments

To prevent typos from passing silently, get_or_create() and update_or_create() check that their arguments are model fields. This should be backwards-incompatible only in the fact that it might expose a bug in your project.

pytz is a required dependency and support for settings.TIME_ZONE = None is removed

To simplify Django’s timezone handling, pytz is now a required dependency. It’s automatically installed along with Django.

Support for settings.TIME_ZONE = None is removed as the behavior isn’t commonly used and is questionably useful. If you want to automatically detect the timezone based on the system timezone, you can use tzlocal:

from tzlocal import get_localzone

TIME_ZONE = get_localzone().zone

This works similar to settings.TIME_ZONE = None except that it also sets os.environ['TZ']. Let us know if there’s a use case where you find you can’t adapt your code to set a TIME_ZONE.

HTML changes in admin templates

<p class="help"> is replaced with a <div> tag to allow including lists inside help text.

Read-only fields are wrapped in <div class="readonly">...</div> instead of <p>...</p> to allow any kind of HTML as the field’s content.

Changes due to the introduction of template-based widget rendering

Some undocumented classes in django.forms.widgets are removed:

The Widget.format_output() method is removed. Use a custom widget template instead.

Some widget values, such as <select> options, are now localized if settings.USE_L10N=True. You could revert to the old behavior with custom widget templates that uses the localize template tag to turn off localization.

django.template.backends.django.Template.render() prohibits non-dict context

For compatibility with multiple template engines, django.template.backends.django.Template.render() (returned from high-level template loader APIs such as loader.get_template()) must receive a dictionary of context rather than Context or RequestContext. If you were passing either of the two classes, pass a dictionary instead – doing so is backwards-compatible with older versions of Django.

Model state changes in migration operations

To improve the speed of applying migrations, rendering of related models is delayed until an operation that needs them (e.g. RunPython). If you have a custom operation that works with model classes or model instances from the from_state argument in database_forwards() or database_backwards(), you must render model states using the clear_delayed_apps_cache()method as described in writing your own migration operation.

Miscellaneous


Features deprecated in 1.11

models.permalink() decorator

Use django.urls.reverse() instead. For example:

from django.db import models

class MyModel(models.Model):
    ...

    @models.permalink
    def url(self):
        return ('guitarist_detail', [self.slug])

becomes:

from django.db import models
from django.urls import reverse

class MyModel(models.Model):
    ...

    def url(self):
        return reverse('guitarist_detail', args=[self.slug])


Miscellaneous