So, I'm still at 1.4.10 for my startup that's still in private beta. I'm feeling left behind very rapidly. Is the effort to update from 1.4.x to 1.7.x worth it before going public? Also, as a general policy, is it best to always stay one version behind?
Take a look at the release notes for 1.5 and 1.6, and see if there's anything there that would be useful to your project. I would advise keeping as current as you're able to, to reduce the migration costs in the future. Migrating to 1.5, testing, and then to 1.6 would probably be the best way forward.
Just take a look at the backward incompatible changes in both sets of release notes to get an idea of how the migration will affect you. There are lots and lots of nice improvements in 1.6 and especially 1.7 that you may be interested in.
At least get to 1.5 before you have significant data. Get proper time zone support now while it's still painless, particularly if you have an app that relies on sensible time representation.
Also, remember that when 1.7 is released, 1.4 will no longer received security updates, only 1.5 and 1.6 will.
Ah, sorry, I'm mistaken about the 1.4 series specifically. It was designated an LTS release and is scheduled to receive security updates through March 2015 [1].
However, this is only security updates, not necessarily bug fixes.
> Is the effort to update from 1.4.x to 1.7.x worth it before going public?
Having recently upgraded two production projects from Django 1.3 to 1.6, I'd say YMMV but it likely isn't. Go public unless you have someone at hand with enough eagerness and knowledge of the codebase to do the migration quickly so you don't have to postpone the release.
The migration itself is no big deal, as others pointed out—you just make a checklist of backwards-incompatible changes and walk/grep through the codebase for every item. I don't think any DB schema migrations were required. Took me two days a project, not counting manual testing afterwards (unit tests were there, which is convenient but can't guarantee that everything will work).
The process is not very exciting, though. It helps when codebase is stable and you have the time to go through it without rush and make sure everything works for some time after deploying the upgrade to production (being ready to roll back quickly). That's also why I'd suggest going public and leaving Django upgrade for later, when things calm down a bit.
1. How many 3rd party apps are you using? Be especially wary if the a) perform any clever black magic on Django internals or b) are only lightly maintained and the job of updating them might fall to you.
My app actually broke going to 1.6 so we had to go to 1.5. At some point soon we'll try again to see what went wrong, but I remember looking into it and it was actually a bug in 1.6.0 iirc.
We recently upgraded a large Django app from 1.4 to 1.6, we actually begun the transition when Django was on 1.6b1 as we hoped they would hit stable before we were ready for production (they did). To be honest the only issues we had were 3rd party apps that had not been updated, which wasn't surprising as 1.6 was still in Beta when we began. And as 1.6 neared release we found fewer and fewer apps that still had problems.
Beyond that it was pretty straight forward, but it really helps if you have good unittests to begin with.
In the final stages of upgrading a 1.4.x project to 1.6. The process seems to have been very simple, other than two very specific bugs that you are unlikely to run into (one had to do with our own code and how it interacted with django_compressor, the other was in the Oracle driver which I doubt you are using).
Do the upgrade. Just read the release notes for every release between the versions you are going through and make sure to make the changes they suggest/require. It'll take you 2 hours and yes it is worthwhile.
Is there a good guide for going from 1.4 to 1.6?