Chicken Scratches

Eddie’s Django Tip #4: Stay Up to Date

The Persistence of Memory

By some measures, Django is still shiny and new. Originally created in 2003, it’s newer than my car. A house built that year would be considered pretty much fresh from the oven. A baby born in ’03 would be just entering sixth grade now. But by Internet time, it’s been around practically forever. Especially because Django has been under constant development for that whole time.

The fundamental concepts and philosophy of Django have not changed much, but there have been significant features added and modifications made to the way many components work. This is especially noticeable to those of us who have been using it since its early beta days. While I didn’t agree with every change as it was made (auto-escaping in templates, for example), in general Django has clearly been getting steadily better.


New ways of doing old things

Often I find that the fine developers of Django have added an “official” way of doing something that I was doing on my own. Although, of course, since they’re not me and they don’t consult me before implementing their feature, it usually works in a slightly different way. And example of this is the static files module. I had set up a very similar system on my own. For existing projects, I decided to stick with my original setup, but for new ones, it makes sense to use the officially supported version. That way I get the benefit of community based support, and when future developers come along it will look more familiar to them.

But be aware of breaking changes

Newer is often better, but not always. Things can change from release to release in such a way that your existing code will break. For example, in release 1.2, support for Python 2.3 was dropped. Always be sure to check the release notes for the new version and any intermediate versions before performing a Django upgrade. (Obviously, this is good practice for any library you depend on, but when talking about the central framework of your entire site, it takes on additional importance.) Perform the upgrade on your development server first to work out any kinks. And always try to run the same versions on your development machine as on your production machine.

Don’t be a bandwagon jumper

Just because something is new and trendy doesn’t necessarily mean it’s right for you and your project. If your existing approaches are working and don’t pose a security risk, there is often no point in switching to a newer approach. See my above reference to the static files module. Switching my existing projects over to it would just introduce the risk of new bugs, for little gain. Likewise, if your site is running fine in an “older” version of Django and you don’t need new features, think twice about upgrading. This is a judgment call that you will have to make on a project-by-project basis.

It is often worthwhile to upgrade a project that doesn’t necessarily need it in order to keep that project on the same level as your new projects. It makes development and deployment easy if everything is running the same version. So the needs of one application can lead to a decision to upgrade several others. This can be good practice, just be sure to perform a full suite of regression tests after the upgrades.

Track comments by RSS

Leave a Reply