Andrew's blog has some great write-ups of how the new system has evolved: http://www.aeracode.org/category/django-diaries/
Congratulations to Andrew and to all involved.
python manage.py makemigrations
python manage.py schemamigration app_name
Basically, create a table as a copy of the old table, set up triggers to update the new table as data pours into the old table, alter the new table, and then do a rename.
This buys you some rollback capabilities, but more importantly it limits the impact on production traffic as the alters run. Of course, this is only really an issue on tables with hundreds of thousands of rows, but it's better than the naïve approach.
Or, use postgres!
Then again, I do most of my DB maintenance manually (I have DBA experience), so while I do use Django in production, I have less need to rely on generic automation tools.
Or use PostgreSQL, Oracle, MSSQL, or... lots of options there.
[EDIT] As a final thought on the topic, never be afraid of making schema changes, even in MySQL. It may require a bit more work to implement, but there are a bevy of solutions (most of which can be automated) which can limit or eliminate the "pain" caused by such alters.
ALTER TABLE RENAME foo foo_old;
-- You're down right here!
ALTER TABLE RENAME foo_new foo;
-- …and we're back!
Plus, PXC uses innodb under the covers as well, which means you still have to wait while alters on tables occur, and that they can not be done in transactions (well, not entirely true, but close enough for these purposes).
Happy about the news!
What's been implemented now is significantly better than what South had. If they'd just decided to adopt South, that wouldn't have happened. Thus, it's good that it happened. :-)
It existed. Django is able to generate SQL DDL on a per-app basis since the first versions. The problem is that people wanted an automatic way of doing that, but there a couple of different approaches. South (and the proposed built-in feature) is not the best approach to everybody.
Also, thanks for supporting Oracle straight away. When you first mentioned the kickstarter I noted the possibility that oracle support would either lag or be missed entirely, effectively making oracle support in django a second-class citizen.
I'm starting a new project in a few weeks (on Oracle RAC), so I'll try to test as much as possible.
This is a fantastic feature. I've worked on projects that use a South fork that only uses a migration number, eg 0003.py, specifically to cause version control to trigger a merge conflict.
I love python, but I would rather use Rails for web stuff at this point. So many 3rd party libraries are needed to do what Rails can do right out of the box.
IMHO, for new projects, DJango is clearly one of the top contestant.
Can you give me some specific examples of stuff Rails does but Django doesn't?
Also, Ruby sucks. I know over a dozen languages, but every time I've tried to learn Ruby it's been an awful experience that's ended with me quitting in frustration at the totally unnecessary obtuseness and complexity of the core language's syntax  , before even getting into the enormous number of additional moving parts in a web framework as complex as Rails.
Regardless, using 3rd party libraries anywhere is pretty straightforward these days, so I don't see how the inconvenience of adding a library to your requirements list could outweigh the fact that Rails means you are using Ruby when you could be using Python.
Other than that, what is your definition of a "data migration"?
you could manage that operation using a Python script, but it would potentially be slow and might make it hard to take advantage of database specific features. A data migration tool allows you to describe this operation in succinct declarative code and then the migration tool will figure out how to get the database to do that with maximum safety and efficiency.
or you could do it in raw SQL as well, but thats a bit uncomfortable if your project has used the ORM interface for all database operations. you'd also have to write different SQL for each backend. a data migration tool can generate the correct SQL for any backend you plug in.
Although, after reading your comment, I'd never taken 3rd party libraries into account. Adding/changing timezone support to a datetime field is a really good example of when that might be necessary.
The groundwork has been laid with an API and supporting infrastructure for schema migrations though. It looks like it should be possible to implement data migrations by adding Operations to django.db.migrations.operations, and suitable sql and methods to each of the backends. You could then hand-craft the migration files.
I'm assuming that the logic behind migrations wouldn't verify the database/model structure before running such a data migration which is probably flat out wrong though.
Imagine the difficulty involving forward and backward data migrations. I cannot imagine a way to automate this.
In any case, you can't have it both ways. Either you do it in SQL, or you do it in Python using the ORM. There isn't a third option.
Django is a working car, the comes with a lot of features, and is more difficult to customize (and you eventually have to start hacking at it for custom features).
Flask is the assembled chassis, engine, steering (no frame, body). It's up to you to build it into a car of your choice.
Eventually though you will have to look at tuning the base system for your special special system.
I wouldn't sweat it tho - the 1.5-1.6 cycle has been pretty quick, and I'm sure as soon as the migrations work is ready and tested the Django core team will be pretty eager to push a 1.7 release.
pip install south
pip install django south
Here, Google even backs us up on this - https://www.google.com/search?q=define%3A+out+of+the+box
"Out of the box is the term used to denote items, functionalities, or features that do not require any additional installation. ..." - via http://en.wikipedia.org/wiki/Out_of_the_box
Rails still makes you write your migrations by hand. It also forces you to distribute your critical constraints, validations and dependencies over a usually incomplete model class, and incremental migration files.
In Rails/AR there is no place in the filesystem to find out about the currently declared schema.
It's a fundamentally broken design.
If you don't know the difference between AR and a declarative ORM you may want to refrain from dropping smarty oneliners.
Over the past 15yrs I've written web-apps in 7 different languages and a wide range of frameworks.
From your comment I can infer that you know Ruby on Rails, and that's pretty much it. Maybe you should reconsider your tone?
Most users of SQLAlchemy tend to use several libraries anyway, as opposed to one framework (the Django style).
This was one of the failing points of south in my opinion.
2013 and you still can't build a REST application without installing 3rd party code? I mean c'moon there's angularjs, emberjs, knockout, extjs etc etc etc out for years don't you see a light at the end of the tunnel or you're the type of team that build more tunnel?
Sorry to say but news like this just make me sad. Still happy I chose flask + sqlalchemy for my website. Django is somewhere in 2004-2005 still. I lose the admin of course but I hate general things anyway (one size fits all type of thing).
I started before Flask supported Python 3, so I used bottle, psycopg2 and a bunch of other python packages. Knowing what I was interested in accomplishing, I was pretty easily able to stitch together these libraries to create a solid, to-the-point codebase.
Having spent a bunch of time working on various backbone-heavy apps with Rails I don't have much interest in using a big, full-stack, opinionated framework to act as a REST API. There is so much overhead and so many opinions to work against.
That answers your complaint. There are many choices, no clear best choice. Frameworks need to balance being not too opinionated (making choices for you) and being convienent/batteries included.
South, over time, became the obvious, best choice.
When a REST plugin gets to same level it probably will be added.
In meantime, doing pip install REST plugin of your choice and adding a single line to installed apps is easy enough even an incompetent developer can do it.
Because I know of no such thing -- it's still very much roll-your-own or use a third-party library.
Of course you can. There are some third party apps that might save some time.
Still happy I chose flask + sqlalchemy for my website.
Disclaimer: I like Flask, I like Django. I've used both for cases where they were the most appropriate choices. Different philosophies, apples to oranges. The poo-poo'ing Django for not baking schema migrations in is silly. The poo-poo'ing a great kickstarter project is even more silly. We chipped in without a thought to make this happen quickly, and it was worth every penny for us.
There have been a number of attempts at schema migrations with Django, and the devs correctly weren't in a rush to main-line them before things shook out. The community eventually settled around South and Andrew's excellent leadership.
Now that we had a methodology picked out, the only barrier was finding the time to get this baked into mainline. We essentially paid for Andrew to get this done fast and well, and he has delivered. If anything, I'd like to see MORE Kickstarting of these larger projects in the open source world. I'll gladly chip in if I'm building a business using your software. It's a no-brainer investment with a high probability of good returns.