Hacker News Reader

Comment by jordigh | Hacker News Reader

I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't have done.

Going to Python 3 is going to be the biggest annoyance yet.

View on HN

That's surprising to me as I have updated a large production Django code-base on my own for every version from 1.5 to 2.0 and it has never taken me more than a day, with an equal or lesser (typically lesser) amount of time dedicated to deprecations when I updated to the previous version. Any blockers past that point have always been due to slow-to-update third-party libraries.

The Python 3 update took longer and had a longer legacy of surprise breakages, but I don't ding Django for following the intended life cycle of Python.

My guess here is that still being in Python 2 makes this more difficult.

If you're in Python 2 the bytes/str story is still mixed up, so API solidification happening in Django iteratively (in preparation for Django 2.0) will likely break a good amount of your code.

Inversely, we moved over to Py3 in the 1.7 days so we were spared some pain on that end.

> That's surprising to me

I'm surprised you're surprised. Have you seen the size of the breaking changes documented with each release notes? We typically hit about 10 of these changes per release, sprinkled all over our code.

https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar...

https://docs.djangoproject.com/en/2.0/releases/1.9/#backward...

https://docs.djangoproject.com/en/2.0/releases/1.8/#backward...

And those are just the intentional breaks. We find a lot of unintentional breakage too, and sometimes we accidentally use undocumented stuff which of course also isn't documented when it breaks. Each Django release has added an average of 32 commits per release for the past four releases just to deal with the version upgrade.

Some things to do that could help everyone (this is what I do):

If documented stuff changes, Please report it (though that likely means testing against the alpha / beta versions (or just master). Keep Django honest.

If you find yourself using undocumented features, consider documenting them; that way they’re held to backward compatibility.

Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.

Disclaimer: Core dev now, though I had this attitude before that too.

> Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.

I really don't want to be sucked into Django's drama:

https://us.pycon.org/2015/schedule/presentation/381/

I've encountered very little sympathy from Django developers. Everyone seems to have just accepted that it breaks often and it's totally my fault for not keeping up with the breaking changes. Everyone seems to think that Django breaking compatibility all over the place is good, proper, acceptable, and inevitable. Nothing is sacred, anything can break, and make sure you go through that list each release to see what you have to change in your code.

This makes me sad and frustrated.

http://stevelosh.com/blog/2012/04/volatile-software/

I hear you, and I've heard others say the same.

I think it would help if you bring it up on the Django-developers mailing list, if you haven't yet. I think that would help raise awareness about the issue, and I hope it would lead to some policy changes.

I have been writing Django professionally since 2013, It's ain't that bad. Our codebase is huge & it never takes us more than 2 weeks to do it and lately, it has always gotten less and less. Wonder if the issue is with your codebase that it breaks so much on upgrades.

Python3 upgrade is a task, agreed. But it actually gives good returns. The language is nicer to write in and we even saved some memory and CPU on the same load after the upgrade. So highly recommended.

Saved some memory and CPU after the upgrade? Could you give some numbers?

https://thenewstack.io/instagram-makes-smooth-move-python-3/

How has Python 3 performed since then?

"Ding: We did not have performance gain expectations for Python 3 right out of the box.

So it was a pleasant surprise to see 12 percent CPU savings (on uswgi/Django) and 30 percent memory savings (on celery).

It’s only been four months since rollout, we don’t expect to see constant 10 percent performance improvement, but that was a very promising start."

Removing the 2/3 compatibility shims saves a lot of code and runtime cost, that could be a contributing factor.

Good point.

Huh. At my last job, we went from 1.7 to 1.11 and while it wasn't seamless, I suspect we spent about that much actual work time making upgrade-related changes/fixes (120ish person-hours) for all of those upgrades combined. We hadn't jumped to Python 3/Django 2 before I left, but we were starting to plan for it. I knew it was going to be painful, but that's part of the cost of holding out for so long, isn't it?

> You could say that this is our fault for "doing it wrong"

Do you have decent test coverage and use tox to run your tests against multiple versions of Django?

If not I can recommend this approach from experience.

I am currently upgrading a code base from 1.4 to 1.5.12 as a weekend project.

On the plus side the original authors managed to avoid using Django features so that makes it a bit easier. Someone actually wrote their own ORM in the process

Reply on news.ycombinator.com