overview of changes and the need for updating

Short description

Django Web Framework, an open-source framework for web development in Python, released a new LTS version in April 2023. The latest version, 4.2 LTS, offers new features such as support for the Psycopg 3 library, the ability to add comments to tables and columns, improved protection against BREACH attacks, and in-memory file storage. Django’s developers have also introduced updates such as compatibility with Python, support for time zones, Redis support, and asynchronous interfaces for views and ORM. While upgrading to a new version may offer improved capabilities, it should be done based on factors such as vulnerability remediation, new opportunities, and compatibility with other solutions.

overview of changes and the need for updating

In April 2023, a new LTS version of Django Web Framework, one of the most popular frameworks for web development in Python, was released.

“A new version is out! Why haven’t you switched to it yet? — this question often arises from students who study this framework in programming courses. A similar question can be heard from a novice specialist who has recently started performing his duties as a backend developer.

Should I start a new Django project or learn this framework? In this article, I will help you deal with these and other questions. We’ll talk about the different types of Django releases, look at the main changes in the new one, and touch on the main aspects to consider when upgrading a Django version in a project.

The difference between releases

First, let’s take a look at the different types of framework updates that are available to developers. They are divided into three main categories:

  • Feature releases (Feature releases). These are updates that usually come out every eight months. They include new functions, features, optimizations and improvements to existing components.

  • Patch releases. These updates are released on an as-needed basis and are designed to address bugs, security issues, and other bugs identified in the relevant feature releases. Patch releases allow developers to maintain the stability and security of their products.

  • LTS-releases (Long-term support releases). Some feature releases acquire the status of LTS, which means “long-term support”. In such releases, security and stability fixes are guaranteed to be released for a certain period of time, usually three years. This provides developers with the ability to use stable versions of the framework for their projects without fear of rapid obsolescence of the selected version or the end of developer support.

All released releases are always available for download. In practice, this means that you can install and use any released version, for example, Django 1.4.22, but you will not be able to update to it.

At the time of writing, the latest LTS version is 4.2 LTS, which will end extended support in April 2026. Updates to the previous LTS version of Django 3.2 will stop being released in April 2024.

If your project uses version 3.2, don’t worry. After the end of support date, the project will not turn into a pumpkin: just for this version of the framework, patch releases will stop.

Overview of Django’s key changes in version 4.2 LTS

Whenever a new version of the software is released, it is accompanied by a detailed overview of all the changes. Let’s see what’s changed in version 4.2 based on the official documentation.

  • Support for the Psycopg 3 library has appeared

    django.db.backends.postgresql is a Django database adapter for working with PostgreSQL. This adapter provides an implementation of PostgreSQL-specific features and allows you to use this database in Django.

    Now supports psycopg library version 3.1.8 or higher. To use the new feature, it is enough to install the psycopg library, and the adapter itself does not need to be changed in the settings. It is also worth remembering that support for psycopg2 will probably be discontinued in the future.

  • It is now possible to add comments to the table and its columns when describing the model

    Such new parameters as Field.db_comment and Meta.db_table_comment , allow you to add comments to columns and tables, respectively. For example, like this:

    from django.db import models
    class Post(models.Model):
        text = models.TextField(db_comment="Post text")
        pub_date = models.DateTimeField(
            db_comment="Date and time when the post was published",
        class Meta:
            db_table_comment="Post details"

    This feature can be useful for documenting fields for colleagues who have access to the database but not to your code.

  • Improved protection against the BREACH attack

    The abbreviation BREACH stands for Browser Reconnaissance and Exfiltration using Adaptive Compression of Hypertext. It is an attack on web applications that exploits data compression and cryptography to gain access to sensitive information. It sounds complicated, but practically everything is simpler.

    Websites and browsers commonly use data compression (such as Gzip) to reduce data size and speed up page loading. They also almost always use the HTTPS protocol (encryption) to protect data transmitted from interception by attackers.

    A BREACH attack uses a combination of compression and encryption to gain access to sensitive data by analyzing traffic between a user and a website. The attack is carried out by repeatedly sending requests to the target website and analyzing the differences in the size of the compressed responses. This allows an attacker to gradually gain information about encrypted data such as tokens or passwords.

    Django developers have made life difficult for hackers: the GZipMiddleware middleware adds up to 100 random bytes to the gzip response to make such attacks more difficult.

  • In-memory file storage is now available

    django.core.files.storage is a Django module that provides mechanisms for working with file storage. It defines the base class Storage and several standard implementations that allow you to process and store files on different storage systems.

    New class django.core.files.storage.InMemoryStorage provides the ability to save files in RAM. This feature is convenient to use for various tasks, for example, for code testing. By refusing to access the disk, you can speed up the work of automatic tests that need to interact with files.

These are only some significant innovations; in addition to them, there are also a huge number of minor changes, as well as changes related to disabling outdated features.

Some other updates released after the 3.2 LTS release are also worth noting. In particular, in versions 4.0 and 4.1, the developers highlight the following:

  • Compatible with Python
    Starting with version 4.0, Django does not guarantee compatibility with Python versions 3.7 and below.

  • Working with time zones
    Django 4.0 and above use the zoneinfo module included in the Python 3.9 standard library to support time zones. If Python 3.8 is used, the package is now automatically installed along with Django backports.zoneinfo.

  • Redis support
    Added new backend django.core.cache.backends.redis.RedisCachewhich provides caching support using Redis out of the box.

  • Asynchronous interface for ORM
    Django developers are gradually introducing asynchrony support into the framework. Asynchronous views and middleware appeared in Django 3.1, and since version 4.1, the Django ORM can also handle asynchronous requests, although the ORM itself remains synchronous.

  • Support for asynchronous methods for classes-views (Class Based Views)
    Starting with version 4.1, when describing a representation class, in addition to synchronous methods, asynchronous methods are also allowed. But you can’t mix them: all methods must be either synchronous (defined using def), or asynchronous (defined using async def). Django will automatically detect asynchronous views and execute them in an asynchronous context.

When should I upgrade to a new version?

Most Django projects currently in use use version 3.2 of the framework. If you get a Django project at work, then with a high probability its version will be lower or equal to 3.2.

When a new version of the framework is released, developers, as a rule, do not immediately try to transfer their projects to it:

  • most often this is a technically complex task that costs time and money,

  • it is irrational to transfer a working project to a new version of the framework: the added capabilities are not worth the costs that the transition to a new version will require.

And this applies not only to frameworks, but, for example, to the version of the interpreter. You’d be surprised, but many projects are still being developed in Python version 2.

The decision to upgrade the version of Django in an existing project should be based on a number of factors. Let’s consider several situations when you should upgrade your version of Django.

When to update:

  • Vulnerability remediation and support. If your project is popular and prone to constant attacks, and your current version of Django is no longer officially supported, upgrading to a supported version can be critical. For example, if a certain report of a new serious vulnerability comes out, you should be able to quickly install a security update. And if you’re using an old version of Django, it just won’t be there.

    There is a period when two supported LTS versions overlap in time – this is a one-year period when the transition from one LTS version to another must be completed. In this case, you can continue to receive bug fixes and other security updates.

  • New opportunities. If a new version of Django offers improvements that you really need and that it is not possible or practical to implement them yourself, you should upgrade to the version you want.

  • Compatibility with other solutions. Updating Django may be necessary if other packages or dependencies in your project require a newer version of Django and there is no other way to ensure their compatibility.

When not to update:

  • Stability. If your project is stable, works without problems, is not critical to the business, and simply does not need new features, then there is usually no point in upgrading. The only exception will be the situation when a vulnerability incompatible with the safe continuation of the project is found in the used version.

  • Compatibility risks. Updating the version of Django may result in incompatibilities with third-party libraries linked to the project. For example, if the new version contains changes that are incompatible with your project, it will definitely not bring anything good.

  • Limited labor resources. Updating Django may require time and effort to fix compatibility issues, test, and deploy changes. If all developers are busy or there are higher priority tasks, it may be worth delaying the update.

In general, the decision whether to upgrade a version of Django in an ongoing project should be based on a balance between the potential benefits and risks, as well as the available manpower. Before upgrading, always study the documentation and changelog carefully to understand what changes may affect your project.

And which version of Django is best to use at the stage of learning the framework?

In the training course “Python developer” in the Workshop, in theoretical lessons, practical tasks on the simulator, as well as when creating and submitting projects, it is used Django version 3.2 LTS.

However, it should be noted that the training result does not depend on the specific version of Django used in the training projects. After all, the main goal of the course is to provide students with fundamental knowledge and key principles of working with the framework. Between different versions of Django, these principles hardly change, and if changes do occur, they are rare and only concern specific details such as those described above.

After completing the course, students are armed with sufficient knowledge to work successfully — including with new versions of the framework, including those that have not yet been released. Understanding the basic principles of Django will allow you to move to new versions of the framework without much effort.

To see a list of current versions of Django, you can visit the official documentation.

Should I even start a new Django project?

According to various studies, for example from JetBrains, a significant part of active web projects in Python are written using one of three frameworks: Django, Flask or FastAPI.

At the same time, the key players do not change from year to year, only the percentage distribution between them changes. This means that Django can be a good choice for a new project. And the presence of good documentation, a huge community of developers and regular updates are proof of this.

If as a result your choice fell on Django, then my advice is to use the LTS version. But in any case, the final choice of the framework and its version always remains with the development team.

Related posts