Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I lived and suffered this tension between stability and security for years running a tech team. Staying on the upgrade treadmill while delivering actually important product features for the business. Hopping from LTS to LTS is a solid default strategy when you can use it.

So pardon the plug, but finding a happy middle-ground to exactly this problem for Django based projects is what I now work on with https://www.codestasis.com/

Projects that can't upgrade, because of the ensuing cascade of breaking changes and dev time needed, subscribe to CodeStasis to minimally update Django to new non-breaking patch versions.

So you can keep your trusty old version yet also stay patched and secure if you find someone to do the heavy lifting for you at reasonable cost, which I think we deliver.



sort by: page size:

Congratulations to the Django project and contributors on a big LTS release. And a huge thank you for the consistently excellent framework that so many have built their web dev careers on.

I'll post this as a Show HN soon, but I'll mention it now as a soft-launch introduction. After a decade of using Django I started a project I always wanted to exist: backported security and bug fixes to old versions that the Django project has dropped support for.

I've seen many Django projects eventually get stuck on an old version as the team I'm on is forced to defer upgrades in favor of commercial pressures and essential product delivery.

So you can subscribe to https://www.codestasis.com/ to stay patched on your old version, removing the urgency to upgrade. Then unsubscribe when you're caught up.

It's free for personal use and a paid subscription for businesses and organizations.


If you can convince your company to keep Django up-to-date with every release, I have found this to be easy and pain-free (Django has been pretty API stable since ~1.8), compared with waiting for each LTS and then being forced to jump ahead three versions each time.

You also gain access to new features as they come out, this way.


Ditto leetrout: upgrading Django itself is easy, with great release notes, deprecation warnings, and long support windows for old versions.

We always end up with a bunch of third party libraries, though, and those end up being upgrade blockers.

A notable example recently was django-tastypie, which didn't cut a Django 1.10-compatible release for 11 months after it came out -- four months after Django 1.9 lost security support. So part of our Django 1.10 upgrade was moving to another REST framework.

(If you don't want that kind of churn, sticking to LTS would make sense - I think 1.8 still has support.)


I remember working on projects that did this in the early days of Django, particularly when there were badly needed features that took too long to land in the stable release.

Nowadays most projects I've seen use the latest stable release or at least the latest LTS - maybe some legacy projects lagging behind.


The biggest challenge with upgrading Django is making sure all your Django-related dependencies have fixed things up.

Django only has one paid full-time maintainer to my knowledge (Tim Graham). So given the team's limited peoplepower Only the last two releases (+LTS releases) get security updates. This means that Django 1.10 (released 18 months ago) won't get updates, so if you use any new features you're on the upgrade treadmill.

Django itself is very good about offering clean upgrade paths. Very vocal about breakage, usually will not introduce breakage unless there's some good reasons to. Unfortunately third party libraries often take a while to update, so you can quickly find yourself overwhelmed with figuring out which deps are safe to upgrade and which aren't.

I try to be a good OSS citizen and send in compatibility fixes for libraries that fall behind, but maintenance can be hard when you're only really using about 25% of a library.

I wouldn't be comfortable with sticking to older Django LTS releases (there was still a lot of obvious improving to be had in the ORM and migrations in particular), but I think Django 2.0 is in an amazingly good place now. Sticking to this for a couple years would be fine for a lot of people.


Django has the same problem. You either have to upgrade all the time, or you have to jump LTS to LTS, which is also not advised from Django's perspective.

I don't have any projects using Django but they have an LTS model - surely you don't need to update to avoid being vulnerable? Just security patches?

Nobody is forcing you to update your Django by the way. My business is still on a pretty old version and none of the dependencies are in any way insecure.

There’s certainly also the probability of new holes in the newest libraries so keeping to the old ones is okay.


A whole pile of people complaining about upgrading Django highlights two things to me:

Not enough people are using tests. A decent set of tests make upgrade super easy. The upgrade documentation is decent so you just spend 20 minutes upgrading broken things until it all works again.

People pick the wrong version. I've seen people develop and even deploy on -dev and it makes me cry inside because they'll need to track Django changes in realtime or near enough. Pick an LTS release and you get up to three years on that version with security and data-loss upgrades and no API changes.


I've had a Django app running for 3+ years (stick to an LTS release) and it requires a very occasional security update (months in-between) but generally it's a 5 minute change to update the version, run the test suite and then push to prod

Exactly. I'm stuck maintaining a legacy Django 1.3 system and its not ideal. I'm using Django 1.9 for other systems and it makes me a bit sad to work with the older version. I'd happy maintain a legacy system but it gets harder as security fixes become non-existant.

The reason for the LTS versions is in large part for enterprises that are stuck on older versions of Python because of RedHat support contracts and the like.

Django can move ahead and drop support for (honestly very outdated) Python versions like 2.5 and 2.6 so that newer Django releases can take advantage of additional features and nicer syntax in newer Python versions.

And companies stuck on python 2.6 because that's what's bundled in whatever version of RHEL can still get security patches to Django.

It's unreasonable to expect the (volunteer) django maintainers to indefinitely support every version of python or every version of Django.

And if you have no choice of upgrading to Django 1.5 yet, I'm sure you'd rather continue to get security patches until you can upgrade to 1.8.


The author writes that they have a particularly big piece of maintenance coming up.

> The latest change we need is an especially large amount of work, as we will have to move from Python 2 to Python 3.

This sounds like the transition from Django 1.11 to (probably) Django 2.2, if they're moving from LTS to LTS, and it definitely is a big piece of work if you also have to change python versions.

Django defined a release schedule DEP[0] a few years back to try to preference stability and reduce the amount of maintenance when moving between LTS versions, which is approximately every 3 years.

If your application runs on an LTS version without any deprecation warnings, then you should be able to move to the next LTS version without any changes. Which is nice in theory, but 3rd party packages in particular aren't always aligned in such a nice way. If the stars align though, it is 6 years (LTS + LTS) of no changes.

This is all to say, I think the author has a point, but that Django has recognised the maintenance burden as an issue, and has tried to help developers with that as best they can, without just shutting down all progress. I think the balance is mostly right.

Moving from 1.11 to 2.2 should be mostly painless. Unfortunately, moving from Python 2 to Python 3 is going to make that more painful. From 2.2 the maintenance burden should be much less than in previous years. Stick with Django if the features meet your needs.

[0] https://github.com/django/deps/blob/master/final/0004-releas...


Compared to how fast things move in frontend world, Django feel like ultra stable to me. Upgrading an old django project to the latest version typically doesn't affect any fundamental things. Maybe some classes has been moved into contrib or spin off as non-core packages, or some methods has been removed and replaced with another methods, but never fundamental changes that requires you to rewrite majority of your code.

Yeah dependencies are always going to be an issue unfortunately. Django can make as many recommendations as it likes, but you're still at the mercy of all other dependencies.

Moving from 1.9 to 1.10 is different than moving from LTS to LTS. The hope is that 3rd party packages will be testing against LTS releases at the minimum, which should allow you to make the jump after packages have time to update themselves.


Django is a great product. But migrate a large project between versions multiple years apart, and you'll feel it.

I feel your pain. If maintainability is your concern, I would advice to skip this release as it won't have long term support. The current LTS release is still 2.2 and will only be replaced with 3.2 sometime in 2021.

You probably already know, but the long term release timeline is shown at https://www.djangoproject.com/download/

Sticking with LTS releases really helps. You'll still have nearly a year to migrate from one LTS release to the next.

In my experience it also helps to avoid small (e.g. a single developer) and young Django apps and stick to the big ones. The amount and quality of the documentation can also be an indicator of longterm viability of the project.

I've done a few more significant migrations (including Python 2 to 3), and about the only bad things are apps whose development stopped and those with developers implementing hacks using Djangos internal API. Everything else is usually done in less than a day for the whole Django project. I only did small projects with 5-10k loc, though.


TL;DR: always update Django to the latest version you can, if your app is a little bit bigger, jump from one LTS to another may take some time.

LTS is great, if there is some reason that you cannot upgrade when new release comes. But if you use any plugins, just update to the latest version your all plugins support. Some plugins like (or even need) to use internal Django API's and if your app becomes pretty big, you may be tempted to use those internals in some places as well, which makes upgrades more painful due to internal API changes.

Speaking from personal experience of upgrading pretty big and rather legacy app from Django 1.4 to 1.8. Took more than a week.


As someone who built his business on django, I'd say I'm super happy with it. However, my biggest gripe with it is it's continued push for updates with breaking changes.

Moving from django 1/python 2.7 was quite painful but possible and now they're suggesting that third party developers stop supporting django 2.2? It was released in April this year!

I know I'm not using any new django features that weren't there in 1.0. I imagine most django users are the same. I'd love to just have a LTS with security updates and conservative non-breaking changes.

next

Legal | privacy