There’s a feature you’re keen on in Django’s main development branch — as we write, the Database-level delete options for ForeignKey.on_delete from the upcoming Django 6.1, for example.
The release is months away — Database-level deletes were merged in October 2025, after Django on the Med 🏖️, with Django 6.1 not final until Aug 2026.
What’s a girl to do?
Deploy main, of course.
Hear me out.
Django main is, in practice, remarkably stable. Contributions are well vetted, the review process is thorough, and the test suite is enormous. Things land in main when they’re ready, not when a calendar dictates. In addition, the stability policy guarantees that breaking changes are few and far between, and in almost all cases provide an easy deprecation path — Django’s stability is among its key selling points.
This means that the existing features you rely on aren’t going to be affected by the new feature you want.
Regressions can happen, sure, but these are fixed quickly, as release blockers, often before most people have even noticed. You’ve got tests, right? Clone Django, install it in editable mode in your project, and run your tests. Nothing broken? You’re basically good to go. Something did break? Report it.
The main risk is a bug in the new feature you want to use: a bug, a missing detail, an API that gets adjusted before release. But you want the bleeding edge? That’s the cost.
Track your feature during the remainder of the development cycle. Report any issues you find. People run main in production more than you might think. It’s part of how bugs get found. The contributors who run main are often the ones reporting issues that get resolved before the release ever ships. You’d be joining a useful tradition — and doing the project a service. Bugs caught before release are vastly cheaper to fix than bugs caught after.
Two reasonable options.
Option 1: pip install from git.
pip install git+https://github.com/django/django.git@main
Or pin to a specific commit:
pip install git+https://github.com/django/django.git@<sha>
It’s a one-liner. Your requirements.txt (or pyproject.toml) just points at git.
Option 2: build the wheel.
Clone Django, check out the commit you want, and build:
git clone https://github.com/django/django.git
cd django
git checkout <sha>
python -m build
Then install the resulting wheel from dist/. Slightly more setup, but you end up with a real, distributable artefact you can install in CI, push to a private index, or hand to a teammate. For anything beyond a personal project, this is the option I’d reach for.
Don’t track main as a moving target. Pick a commit. Use it. When you have a reason to update — a fix you want, a new feature, a quiet afternoon — pick a new commit and update.
You get the same shape of dependency management you have with released versions. Reproducible builds, controlled upgrades. The only difference is the version string.
Just as when you’re using a release version, you’ll need to watch the Django Blog for security releases. Patches for these are applied to the main branch at the same time as the security releases are made. So, if an issue affects you, you’ll need to update to a commit with the fix applied.
If you hit something, report it. That’s the deal. You’re getting features early; in exchange you help surface the rough edges. Trac is open. The fix will probably ship within the week.
§
Running on main isn’t the left-field idea it first sounds like. It’s a reasonable position for a project that genuinely needs the feature, doesn’t want to wait, and is willing to play a small part in the release cycle. Try it on a side project first, get a feel for it, and you may find you don’t go back.