6 ms·
I'm still stuck with Django 1.4 for one of my projects, it's such a big hurdle to upgrade it. I wonder if it's worth to just straight up rewrite it in 1.10.
by hrayr 10y ago
I'm still stuck with Django 1.4 for one of my projects, it's such a big hurdle to upgrade it. I wonder if it's worth to just straight up rewrite it in 1.10.
- gtaylor 10y ago1.4 to 1.5 is the really painful upgrade. The rest are much less so. Especially after 1.6.
- St-Clock 10y agoUntil you hit the migrations in 1.7. But you are right. At my previous job, I spent countless hours getting from 1.4 to 1.5, but the step from 1.5 to 1.6 was relatively painless.
- merb 10y agoif you can screw your old migrations it's not a big deal.
- mangeletti 10y agoFor others: https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdoption-migrate--fake-initial https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdo...
- St-Clock 10y agoThis was introduced in 1.8 (which is great if you move to 1.8 or beyond), but if you are trying to go step by step, 1.7 was not a fun release to migrate to. There were also many problems with custom user model and the like. 1.7 was a very important release in the history of Django, just not a fun release to move to if you had a large codebase.
- Walkman 10y agoIt's better to do it step by step: 1.4 to 1.5, 1.5 to 1.6, etc. You need to go through the release notes and have a good test coverage.
- bdr 10y agoThis. Go through the deprecation lists and backwards incompatibility lists item by item. Thankfully, they're very thoroughly done. It probably won't take as long as you think!
- mamcx 10y agoDepends. Re-write help in clean code way more that just a upgrade ('cause is a bigger refactoring), but could take longer time. Normally I prefer that, and translate code manually. even more if the jump is big. Except if the goal is just stay current.
- bebop 10y agoI agree with the advice of moving the project forward release by release. With that said, it might be useful to create a new project from the django-admin startproject template, and then add your apps back in. Starting at 1.7, getting everything working and then doing it again with 1.10 would be my recommendation. YMMV though.
- stable-point 10y agoAs others have said, going release-by-release is the way to go. I migrated a project from 1.4 to 1.8 (LTS to LTS) over the course of a few months. It wasn't trivial, but it wasn't too difficult either. The deprecation notices are usually (always?) accompanied by the code giving `DeprecationWarning` messages. These are silenced by default, but can be enabled by setting the environment variable: `PYTHONWARNING=d`. After upgrading to each major version, I'd recommend running with warnings enabled for a little while (in addition to reading the release notes), to see what may bite you at the next jump.
- ergo14 10y agoIt is quite scary for me to read that people have serious issues upgrading their frameworks, wouldn't it be better to use pyramid (or flask eventually) instead? It is very mature and well supported - and the upgrades are usually painless since you can upgrade all the components separately so sqlalchemy for ORM or Jinja2 for templates - whenever you feel you are ready. You will not get things like admin panel as a downside though.
- jsmeaton 10y agoYou get similar issues with libraries that you use for flask or pyramid too though, if you don't upgrade it for 4 years.
- asimuvPR 10y agoNo need to rewrite if you have a good codebase. Just go upgrade one version at a time until you reach your target version. Its not too bad.