Django 1.4.9 and 1.5.5 released • Hacker News Board

Re: Django 1.4.9 and 1.5.5 released

#21

Post by erichurkman » Fri, Oct 25, 2013, 6:37 PM UTC

michaelmior wrote: post #18

thraxil wrote: post #13

Earlier quoted context omitted.

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).

Re: Django 1.4.9 and 1.5.5 released

#22

Post by raverbashing » Fri, Oct 25, 2013, 7:33 PM UTC

Demiurge wrote: post #12

jsdalton wrote: post #9

Earlier quoted context omitted.

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.

Makes me pat myself on the back for trying to resist non-essential packages if I can roll my own, as much as possible :)

Yes

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.

Re: Django 1.4.9 and 1.5.5 released

#23

Post by vadl » Fri, Oct 25, 2013, 9:01 PM UTC

nilsbunger wrote: post #11

tocomment wrote: post #4

Just curious, how badly would an upgrade from 1.2 go? I want to do it if it takes less than a day.

1.4 to 1.5 is the biggest change. 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 y…

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.

Re: Django 1.4.9 and 1.5.5 released

#24

Post by azernik » Fri, Oct 25, 2013, 11:00 PM UTC

vadl wrote: post #23

nilsbunger wrote: post #11

Earlier quoted context omitted.

1.4 to 1.5 is the biggest change. 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 y…

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.