Supported versions: Django vs. FastAPI vs. Laravel
Comparing supported releases across ecosystems
It’s always interesting to consider – “what if” Wagtail was started as a brand new CMS today, instead of 11 years ago. Would we be using another framework? Hard to tell, but even now, there’s lots we can learn from those other ecosystems.
Part of Wagtail’s appeal is the stability and guarantees that come from Django, the underlying web framework. For us maintainers, it’s a strong foundation to build custom features on (live preview, block-based editing, etc.). For Wagtail users – it’s not an instant website in a box (👉️ Zen of Wagtail). It’s meant for people who want to be using Python, to set up their site just so. And they expect that setup to keep working over the years, through many releases of the underlying framework!
Releases over time
We can visualize how popular Django releases are, in a neat stacked area chart. This gives us a sense of how developers deal with upgrades over their project’s lifespan. With the Django 5.2 release right around the corner, it’s just the right time to capture this.
Here’s FastAPI’s version adoption chart as a point of comparison:
And Laravel’s, courtesy of Packagist, though as a line chart rather than stacked area:
Comparing this data, as of today,
- 75% of Django downloads are for a supported version (Django 5.1, 5.0, 4.2 LTS)
- 34% of downloads are the latest version (Django 5.1)
- For FastAPI, 65% of downloads for the latest (and only supported?) version.
- 52% of downloads are for a supported Laravel version (Laravel 12 and 11)
- 16% are for the latest version (released a few weeks ago, makes sense).
There aren’t necessarily any "right" or "wrong" numbers here, just tradeoffs to be made on how much emphasis is placed on upgrade-ability, using the latest version, and time spent addressing the needs of existing users or future ones (is there a conflict? you tell me).
Support policies
Django’s policy looks very generous here, with 16 months of support for all releases, and an extra 20 months for Long Term Support releases (so 3 years in total!). Note however that’s not for all bugs, only security / data loss / crashes / major functionality / regressions. Laravel’s policy is much simpler: bugs for 18 months, security fixes for 24. FastAPI doesn’t seem to have a defined support policy, aside from notes about how it’s versioned.
For Wagtail, like all packages, there are clear advantages and drawbacks to long-running policies like those of Django and Laravel:
- The Django foundations will keep working for a while, without having to spend a lot of time on compatibility as new releases come out.
- We have to make sure to keep compatibility with past Django releases, even though they might have been released a while ago.
A good example of this is our latest LTS, Wagtail 6.3 released in November. If we put Django and Wagtail releases on a timeline, its support window overlaps with the upcoming Django 5.2 and 6.0. Should we make extra efforts to make this past release work with Django’s future iterations?
It would be very interesting to compare this with other projects built upon an underlying web framework. It’s certainly interesting to compare ecosystems – for example looking at Laravel Shift vs. django-upgrade. Should upgrade tools be a feature of frameworks? Should they be community projects? Or business ventures?
What “support” means
The underlying question comparing those release adoption charts is what it means for a software version to be "supported". Is it security fixes? Presumably. Are other types of issues also included? It depends. For the Wagtail community, we have our own definition. Navigating this means deciding when to invest into getting started resources and when to focus on upgrade-ability.
As for now – Django 5.2 is due soon, and our latest 6.4 release will work great with it. Check it out!
