I'm currently using 1.4.3. 1.5 will make my front-end development much easier because of the new verbatim template tag.
The release candidate was posted a few weeks ago: https://www.djangoproject.com/weblog/2013/jan/04/15-rc-1/
Is it advisable to upgrade? Where can I find a build status or see outstanding bugs or anything else that's holding up the final release?
This is mostly a judgment call based on your project requirements and your schedule. Technically, I consider 1.5 to be pretty good and the improvements, especially to user model extension, to be invaluable. But it's still under development and bugs are still being found.
If you are developing an app that you don't plan to launch within a month, I would definitely upgrade. I like the new 1.5 features and it will probably be officially released fairly soon.
If you are developing an app that you need to launch sooner than that in a high-stress environment, I would pass on upgrading until after 1.5 is stable.
If you are developing an app that isn't going to see heavy use very soon, then you could go either way, but I would lean towards upgrading.
Related
So Django 1.5 will be out within an Internet-Week (soon) and I'm feeling the pressure to start playing around with it for its vastly improved User model. But like with 1.4 and 1.3 before it, upgrading is not simply a virtualenv change, I've needed to alter (quite heavily in places) the structure of my projects.
I recently jumped from 1.2 to 1.4 and spend hours (over many projects) updating their file structures (and settings) to mirror modern Django preferences. Django 1.5 is going to force me to go through and fix all the CACHE settings and fix practically every instance of {% url ... %} in my templates.. I'm wondering if there's an easier way.
Is there anything out there that can automagically "upgrade" a Django project?
... Or at the very least "scan" a project to show up the larger honking issues so I can kick those out before starting QC.
No. And for good reason.
Some of the changes between versions are minor (such as the whole quotes around variables thing), while some are major (like the new User model).
While automatic detection might be possible (though non-trivial considering you'd have to execute every possible code path in the app), changing them would be fragile. And possible very dangerous.
Instead, when moving between versions, I move up one version (to the last minor version in for that major) at a time and test. Django will issue warnings for features that will be removed between versions, so it's easy to catch them while still having running code that works.
I don't know what I was thinking and I don't have any kind of tests on this project. I want to upgrade it to 1.4 to be able to add to it all kind of different tests and have a more rigid project. What tips or recommendations can you guys give me?
Thanks.
I would recommend you to read through the release notes for each release to try to identify any areas that have changed that might break your existing code. Find them here https://docs.djangoproject.com/en/dev/releases/
Since you don't have any tests for your project you just have to roll up your sleeves and run full site tests where you run your app and try to test as many features you can to see if it is working as epxected.
I have just done the 1.1.1 to 1.4 upgrade (but I had some tests to help me) and it was not that bad.
There are 2 aspects of the upgrade. One is just to get your app to run on the new version and one is to change/update your code to utilize the new features in the 1.4 release. I would recommend that you first get it to work properly, release it and then refactor your code as you go along to use any new feature.
I recall there was a discussion on the future of sorl-thumbnail and big changes coming; now that page is gone… I'm glad that the project is still being actively maintained, but I can't find any mention of backwards-compatibility problem in documentation.
So, what do I need to do in order to update old sorl (v3.2.5) to current version (which is 10.12.1)? Do I need to fix, say, template tag usage or settings?
sorl-thumbnail 10+ is very different from version 3.2.5-. It will require you to rewrite everything that uses sorl-thumbnail if you want to upgrade. However difficult and time consuming this might seem, its usually not such a big job. I have upgraded from the old version to new in numerous projects, some of them very big and ut has been a pretty simple and fairly quick job. Most of all, it has been worth it considering the new features with storage support, quality images using pgmagick and easy admin integration just to name a few. As mentioned the other route is probably to use easy-thumbnail which still has alot in common with the old sorl-thumbnail.
Myself and my team is taking over a DNN web application done by a software development vendor.
There are some issues like
1. redundant non-standard data / API to access to tab and configuration of a module, and
2. some other architecture related issues.
My goal is to remove things we don't need and steer the application back to DNN best practice. I also need to implement a work flow engine with DNN because at the moment the work flow process is "semi-hard-coded".
I am wondering if there are any design pattern / best practice material (especially to do with work flow) that we can follow to ease our pain and help us to prioritize work?
EDIT: the application is not designed with unit testing in mind, but I do not mind changing it as long as I can creating unit test, please help me with something about unit testing with DNN too.
Thanks in advance.
Best case would be to make a copy of the directory, clone the db, and put it separately so you can play around with it. First and foremost, upgrade to the newest version and see what happens with the bought and built modules. I had some problems with old modules that were central to operations not having or not being compatible with the newest dnn version. In all cases, a quick look on snowcovered found me alternates which turned out to be better anyway.
We're not a huge development team, but I found writing out test cases to ensure that functionality is not lost in the upgrade process helped immeasurably.
As I mentioned before, if it's homegrown code that you might not want to bring up to speed or even take over, there are a lot of modules out there that do a lot of cool stuff. Might be worth looking at a fresh install of DNN and migrating what you have to have and going from there.
I've seen Pinax in the past and I'd like to use it today. It's on version 0.7. I wonder know if it's still in development.
It is very alive, as you can see in its GitHub repository
It's very much under active development. Check out http://groups.google.com/group/pinax-users for the latest info.
An important note:
Much of Pinax is Django-apps which are developed separately from pinax and are brought in via version control systems (subversion, mercurial, git, etc)
So even if the pinax project maintainers were to go on a 6 month hiatus (though they are very unlikely to), the platform would continue to be updated and receive bug fixes