Following over 3,000 responses to the Django Developers Community Survey and a long discussion on the django-developers mailing list, the Django team has adopted the following release schedule (subject to change as needed).
The plan is to have a new feature release every 8 months and a new long-term support release (LTS) every 2 years. LTS releases are supported with security updates for 3 years.
| Release Series | Release Date | End of mainstream support1 | End of extended support2 |
|---|---|---|---|
| 1.9 |
[1] Security fixes, data loss bugs, crashing bugs, major functionality
bugs in newly-introduced features, and regressions from older versions of Django.
[2] Security fixes and data loss bugs.
The community was equally split between a twelve and six month release schedule, and we believe eight months is a good compromise. It also makes the release dates align well in terms of having a new LTS every 2 years.
As outlined in our supported versions policy, mainstream support for each feature release (which includes security fixes, data loss bugs, crashing bugs, major functionality bugs in newly-introduced features, and regressions from older versions of Django) lasts until the next feature release is issued (8 months unless delayed). Extended support (which includes security fixes and data loss bugs) lasts until the following feature release (another 8 months unless delayed).
The team has also decided to tweak our deprecation policy in order to ease upgrades from one LTS to the next and to allow third-party apps to more easily support the currently supported Django versions. We observed that most third-party apps didn't consider dropping support for the previous LTS (1.4) until the next LTS (1.8) was released. This meant that all these projects had to implement their own compatibility shims (instead of using Django's) once they wanted to add support for Django 1.6+ because the compatibility shims for deprecated features in Django 1.4 were dropped. This resulted in ugly code with lots of conditional version branches.
The new policy should make it easy to develop an app using the latest LTS release and have it continue to work without many changes until the next LTS. With this schedule, if you start with 1.8 you are already on LTS. If you start with 1.9, you should have an easy upgrade path all the way until 1.11 which will be an LTS release. Also upgrading from LTS to LTS (1.8 to 1.11) should be easy enough if you don't use any deprecated features when running on 1.8.
In order to reflect our new commitment to supporting compatibility shims in a way that eases maintenance of 3rd-party apps and upgrading projects from one LTS release to the next, we'll adopt a loose form of semantic versioning effective with Django 2.0. SemVer makes it easier to see at a glance how compatible releases are with each other. It also helps to anticipate when compatibility shims will be removed. It’s not a pure form of SemVer as each 8 month feature release will continue to have a few documented backwards incompatibilities where a deprecation path isn’t possible or not worth the cost. Also deprecations from each LTS release will be dropped in a non-dot-zero release to accommodate our policy of keeping deprecation shims for at least 2 releases.
Here’s an overview of when deprecated features will be dropped in Django going forward:
- 1.8 - April 2015 (LTS): Dropped deprecation shims added in 1.6.
- 1.9 - Dec. 2015: Drop deprecation shims added in 1.7.
- 1.10 - Aug. 2016: Drop deprecation shims added in 1.8. This still allows running code that was deprecation-warning free on 1.8; the shims dropped are for supporting older unsupported versions.
- 1.11 - April 2017 (LTS): No deprecation shims dropped. The 1.9 deprecation shims are needed to help apps maintain compatibility back to 1.8 LTS.
- 2.0 - Dec. 2017: Drop deprecation shims added in 1.9 and 1.10. Apps may drop support for Django 1.8, 1.9, and 1.10 -- 1.8 support will end in April 2018, approximately 4 months after the release of 2.0, and the other two versions are now unsupported.
- 2.1 - Aug. 2018: Drop deprecation shims added in 1.11. This still allows running code that was deprecation-warning free on 1.11; the shims dropped are for supporting older unsupported versions.
- 2.2 - April 2019 (LTS): No deprecation shims dropped. The 2.0 deprecation shims are needed to help apps maintain compatibility back to 1.11 LTS.
Future versions: 3.0, 3.1, 3.2 (LTS), 4.0, etc.
Following Django 1.11, the version will be bumped to Django 2.0. After that, each version following an LTS will bump to the next “dot zero” version. LTS versions will always be “X.2” and so third-party apps can target support for X.2 to X+1.2. We aren’t bumping Django 1.9 to 2.0 because Django 1.9 has already been anticipated in the docs and deprecation warnings, so such a change is likely to cause more confusion than it’s worth. django.utils.deprecation.RemovedInDjango20Warning in Django 1.8 will be renamed to RemovedInDjango110Warning in the next patch release (1.8.3), and the documentation has been updated to reflect these changes.
As a final heads up, Django 1.11 is likely to be the last version to support Python 2.7 as it will be supported until the end of Python 2 upstream support in 2020. We’ve adopted a Python version support policy as follows:
We will support a Python version up to and including the first Django LTS release whose security support ends after security support for that version of Python ends. For example, Python 3.3 security support ends September 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django 1.8 is the last version to support Python 3.3.
Frequently Asked Questions and Complaints
Q: Will a time-based release compromise the stability of releases? Why not release when things are ready?
A: Release stability will be a continued priority. Releases will be delayed (and thus support for older versions extended) as necessary if there are major, unsolved issues. Thanks in part to the resources provided by the Django Fellowship program, Django 1.8 was released according to schedule.
C: Stop breaking backwards compatibility. Many hours are wasted and money spent all over the world because of this lack of respect for your users.
A: The team takes backwards compatibility seriously. Sometimes it’s necessary to make such changes to continue the long-term improvement of Django. You can help keep us honest by testing and giving feedback on prereleases. If you value stability over new features, the new deprecation policy should make it easier to use only LTS releases and upgrade less frequently.
C: It's great to see features roll out quickly, with one caveat: I'm starting to see third party packages struggle to both keep up and support the LTS packages.
A: Hopefully the new deprecation policy outlined above will help address this.
Q: Why doesn’t the documentation/release notes include an upgrade guide/checklist for porting from past two or three versions (e.g. upgrade LTS to LTS)?
A: The team suggests upgrading one Django version at a time when you decide to upgrade LTS to LTS. We don't believe we can offer an official LTS-to-LTS upgrade guide (maintaining one is simply too much work and would mostly involve copying the release notes from all the intermediate versions). However, the new deprecation policy will make LTS to LTS upgrades easier, as it won’t require dealing with any API removals (as long as your code does not trigger any deprecation warnings on the older LTS version).
C: It would be good if there were more overlap between LTS releases. Right now we have 6 months between the release of the new LTS before the old LTS is EOLed. This makes it very hard for a product company such as ours, where we have to maintain support for a previous release much longer than those 6 months.
A: The new schedule gives one year of LTS support overlap.
C: 3 years is NOT LTS at all, in the enterprise world LTS means 10 years. I would like to have a very stable Django core that updates only on security problems and important fixes that is supported for minimum of five years.
A: With the exception of the Django fellow, the team is composed entirely of volunteers with limited time. Some of us work in large enterprises, so we are aware of these challenges. We believe that if you need support longer than 3 years, you should consider engaging a paid contractor to patch security issues in your Django installation (much the same way that organizations provide similar support for Python).
Q: I’m the maintainer of a reusable application. Which Django versions should I support?
A: We recommend that you support the same Django versions that are supported by the Django team. With the new deprecation policy, it should be possible to support two consecutive LTS releases (e.g. 1.8 and 1.11) and all the non-LTS versions in between without requiring backwards-compatibility shims in your own code, as long as your code runs warning-clean on the lower LTS (1.8), because any non-deprecated feature in one LTS release is guaranteed to remain in place through the next LTS release.