I think the way to upgrade is to do it piecewise, one release at a time.
Here's what we do:
1) upgrade 3rd party packages to latest. I wrote a little script to apply each new package one-by-one, rerun tests, and revert any that fail. Resolve any failures.
2) turn deprecations into errors, run tests again, and resolve any deprecation notices.
3) Read release notes from 1.2 to 1.3 so you have a sense of what's changing.
4) upgrade django from 1.2 to 1.3, then rerun tests.
5) Repeat steps 2-4 with each django release (1.3->1.4, 1.4->1.5).
This way, if / when things break during the upgrade process, you have some isolation as to what changed.
I'm not sure you can get all the way from 1.2 to 1.5 in a day, but if you spend half a day you can get a sense of how far you get, and what issues you have to resolve to finish.
You definitely want to get to at least 1.4, since that's the oldest version that has security patches.
If you don't have good tests? Start by writing tests until you have decent coverage. The django testing page has good info on coverage tool integration.
that doens't have much sense to upgrade to the outdated versions. you should just grasp your balls and start an upgrade to the latest one.
it will take 5x more time to upgrade it version to version. what sense is it to upgrade to syntax and functionality that is outdated and then to rewrite it again and again.
install new version and go ahead fixing things! dont be a pussy.
Some of us place more importance on catching bugs and keeping our product working than on proving our masculinity.
Also, in general there will be very little of the "upgrade to syntax and functionality that is outdated" - while a lot changes in a standard Python/Django release, I don't think there's much that changes in two backwards-incompatible ways in three releases. Most of it will be adapting to one change at a time, which may touch the same line of code more than once, but will not waste much effort and will give you a good idea of what mistake you make when you make it.
Should be reasonably painless. You'll want to read the release notes for 1.3, 1.4, and 1.5, because there are a couple of things that have been deprecated and/or removed. And even a few things that have moved but are otherwise the same. I would think that a day would be sufficient for most peoples' uses of Django. I upgraded from 1.2 to 1.5 a few months ago, and it only took an hour (and this was 10 sites worth of code).
In my experience it isn't the Django upgrades that go poorly, but all of the other packages that I'm using. A day to upgrade from 1.2 seems reasonable. A day to upgrade the rest of your packages might be significantly more time consuming.
I've never actually done a 1.2.x to 1.5.x upgrade in one go, but have done plenty of 1.3 to 1.5s.
As far as I recall, for Django itself, the 1.2 to 1.3, and 1.3 to 1.4 upgrades were pretty painless, but then 1.4 to 1.5 will involve some work if you make use of function based generic views, as that's when they were removed.
Worth looking at whether your third party apps are still maintained with the new versions as well, as you'll likely be on ancient versions of lots of them if you're using 1.2 (and some may even be obsolete). pip-tools is handy for this ( https://github.com/nvie/pip-tools ).
I actually found the 1.3 to 1.4 upgrade to be much more work than 1.4 to 1.5. But that was because I'd been using the old style directory layout, so the whole project structure had to change. And I never used function based generic views very heavily, so that didn't factor in very much.
Interesting. I found the 1.3 to 1.4 upgrade only took a few hours. The 1.4 to 1.5 was a bigger deal because of the new syntax for the {% url %} template tag. Especially since this had to be dealt with in third-party packages.
And for anyone planning on going up in version, you can start getting ready with {% load url from future %} to get the new syntax (URL names have to be quoted strings).
Do you have good tests? I've done this pretty recently and it got somewhat messy -- though I had great test coverage on the project that I upgraded, so it probably only took a day or so.
The main road bump I hit was Django Piston. It's totally broken past 1.5 and there are a gazillion forks that solved non-overlapping subsets of the problems I was having.
Some people will try to solve whatever problem they have by searching for a package. Even if this could be solved with a couple of lines of code
Yes, reinventing is bad. Yes, good libraries have been tested, are supported through upgrades, etc.
But I'm very wary of libraries. Beyond the learning curve, then finding out it doesn't solve your problem or it has some stupid bugs, I think it's usually easier to roll your own except for the most mainstream libraries.
However, Class-Based Views nowadays solve the same problem domain much better, and I would think that it's easier to write a CBV that's support some of Piston's idioms and refactor a bit than try to take Piston the latest Django version.
You can end up in a weird situation with 404s due to timezone settings. Our timezone is set to Europe/London, the get_absolute_url method for any objects between midnight and 1am BST returns the result for the wrong day. The object will still be visible, just not at the expected URL.
If you're using dates for URLs, add an additional DateField, set it to editable=False, add something in save() which sets the date based on the datetime, and use the date field for your get_absolute_url method.
The front page clearly has 1.5.5 as the release and that takes you to a page that has 1.5.5 listed as the latest official version and 1.6 as the development version.
Are you referring to 1.5's Python 3 support? That is experimental, but 1.5.5 itself is not.
How does this impact the release of 1.6, considering that 1.6RC1 was released yesterday? Does 1.6RC1 contain these fixes, or does this mean that 1.6RC2 is coming out soon?
1.6 will inevitably get the fixes, but as it's not a security release and 1.6 is not officially out yet, they'll probably just bundle them with the actual release.
