Why we're not running the current version of Django

June 22, 2017

We have a small web app that uses Django (or is based on Django, depending on your perspective). As I write this, the latest version of Django is 1.11.2, and the 1.11 series of releases started back in April. We're running Django 1.10.7 (I'm actually surprised we're that current) and we're probably going to keep on doing that for a while.

(Now that I'm looking at this, I see that Django 1.10 will get security fixes through December (per here), so we'll probably stick with it until the fall. Summer is when new graduate students show up, which means that it's when the app is most important and most heavily used.)

On the one hand, you might ask what's the problem with this. On the other hand, you might ask why we haven't updated. As it turns out, both questions wind up in the same place. The reason I don't like being behind on significant Django version updates is that the further behind we get, the more work we have to do all at once to catch up with Django changes (not all of which are clear and well documented, and some of which are annoying). And the reason we're behind is exactly that Django keeps changing APIs from version to version (including implicit APIs).

The net result is that Django version updates are not drop in things. Generally each of them is a not insignificant amount of work and time. At a minimum I have to read a chunk of the release notes very carefully (important things are often mentioned in passing, if at all), frequently I need code changes, and sometimes Django deprecates an API in a way that leaves me doing a bunch of research and programming to figure out what to replace it with (my notes say that this is the case for 1.11). Our small web app otherwise needs basically no attention, so Django version updates are a real pain point.

At the same time, I've found out the hard way that if I start delaying this pain for multiple version updates, it gets much worse. For a start, I fast-forward through any opportunity to get deprecation warnings; instead a feature or an API can go straight from working (in our current version) to turned off. I also have to absorb and understand all of the changes and updates across multiple versions at once, rather than getting to space them out bit by bit. So on the whole it goes better to go through every Django version.

I don't expect this to ever change. I don't think the Django developers have any sort of policy about how easy it should be to move from, say, one Django long term support release to another. And in general I don't expect them to ever get such a policy that would significantly slow them down. The Django developers clearly like the freedom to change their APIs relatively fast, and the overall Django community seems to be fine with it. We're outliers.

(This issue is one reason to not stick with the version of Django that's supplied by Ubuntu. Even Ubuntu 16.04 only packages Django 1.8. I really don't want to think about what it would be like to jump forward four years in Django versions when we do our typical 'every second Ubuntu LTS release' update of the web server where our Django app runs. Even Ubuntu 14.04 to Ubuntu 16.04 is a jump from Django 1.6 to Django 1.8 all at once.)


Comments on this page:

By Jinks at 2017-06-22 02:35:41:

This might seem crazy, but have you considered rewriting the whole thing in Go?

From your descriptions over the years the app doesn't sound too complex or convoluted. HTTP, forms, SQL, templates are all part of the Go stdlib, so you probably don't have to venture far out of that, if at all.

You're familiar with Go and this path would make the app subject to the Go 1 Promise, not to mention that a statically compiled native application would insulate you from the whims of the host platform.

That leaves you with the "time to do a rewrite" challenge. Time being the only commodity that's really worth anything in academia. Given that the design is already done, and Python and Go aren't that far apart conceptually, it might still be a viable option that has good potential to alleviate long-term pain.

By cks at 2017-06-22 11:01:34:

Among other issues, a few years ago we decided to explicitly standardize on only using a few languages and environments for all of the tools, web apps, and so on that we write, rather than wind up with a wide sprawl of them. Sadly, Go is not among the languages included (so far), despite my modest attempts to talk my co-workers into it.

(Python + Django is in our standard set, partly because our web app existed before we came to this decision. Django is more or less our official web framework now as a result, although we have older Python-based web things that use smaller scale, more brute-force approaches.)

Written on 22 June 2017.
« The oddity of CVE-2014-9940 and the problem of recognizing kernel security patches
My situation with Twitter and my Firefox setup (in which I blame pseudo-XHTML) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jun 22 00:45:33 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.