version 0.6.5 (15-August-2011):
	* Fixed the version association for baseline evolutions for apps.

	  The new code for installing a baseline evolution for new apps in 0.6.4
	  was associating the wrong Version model with the Evolution. This doesn't
	  appear to cause any real-world problems, but it does make it harder
	  to see the proper evolution history in the database.

	* Added a built-in evolution to remove the Message model in Django 1.4 SVN.

	  Django 1.4 SVN removes the Message model from django.contrib.auth.
	  This would break evolutions, since there wasn't an evolution for this.
	  We now install one if we detect that the Message model is gone.


version 0.6.4 (22-June-2011):
	* Install a baseline evolution history for any new apps.

	  When upgrading an older database using Django Evolution when a new model
	  has been added and subsequent evolutions were made on that model, the
	  upgrade would fail. It would attempt to apply those evolutions on that
	  model, which, being newly created, would already have those new field
	  changes.

	  Now, like with an initial database, we install a baseline evolution
	  history for any new apps. This will ensure that those evolutions aren't
	  applied to the models in that app.

	* Fixed compatibility with Django SVN in the unit tests.

	  In Django SVN r16053, get_model() and get_models() only return installed
	  modules by default. This is calculated in part by a new
	  AppCache.app_labels dictionary, along with an existing
	  AppCache.app_store, neither of which we properly populated.

	  We now set both of these (though, app_labels only on versions of Django
	  that have it). This allows the unit tests to pass, both with older
	  versions of Django and Django SVN.


version 0.6.3 (9-May-2011):
	* Fixed multi-database support with different database backends.

	  The multi-database support only worked when the database backends
	  matched. Now it should work with different types. The unit tests have
	  been verified to work now with different types of databases.

	* Fixed a breaking with PostgreSQL when adding non-null columns with
	  default values. (Bugs #58 and #74)

	  Adding new columns that are non-null and have a default value would
	  break with PostgreSQL when the table otherwise had data in it. The
	  SQL for adding a column is an ALTER TABLE followed by an UPDATE to set
	  all existing records to have the new default value. PostgreSQL, however,
	  doesn't allow this within the same transaction.

	  Now we use two ALTER TABLEs. The first adds the column with a default
	  value, which should affect existing records. The second drops the
	  default. This should ensure that the tables have the data we expect
	  while at the same time keeping the field attributes the same as what
	  Django would generate.


version 0.6.2 (19-November-2010):
    * Add compatibility with Django 1.3.

      Django 1.3 introduced a change to the Session.expire_date field's
      schema, setting db_index to True. This caused Django Evolution to
      fail during evolution, with no way to provide an evolution file to
      work around the problem. Django Evolution now handles this by providing
      the evolution when running with Django 1.3 or higher.


version 0.6.1 (25-October-2010):
    * Fixed compatibility problems with both Django 1.1 and Python 2.4.


version 0.6.0 (24-October-2010):
    * Added support for Django 1.2's ability to use multiple databases.

      This should use the existing routers used in your project. By default,
      operations will happen on the 'default' database. This can be overridden
      during evolution by passing --database=dbname to the evolve command.

      Patch by Marc Bee and myself.


version 0.5.1 (13-October-2010):
    * Made the evolve management command raise CommandError instead of
      sys.exit on failure. This makes it callable from third party software.
      Patch by Mike Conley.

    * Made the evolve functionality available through an evolve() function
      in the management command, allowing the rest of the command-specific
      logic to be skipped (such as console output and prompting). Patch
      by Mike Conley.

    * Fixed incorrect defaults on SQLite when adding null fields. (Bug #49)

      On SQLite, adding a null field without a default value would cause the
      field name to be the default. This was due to attempting to select the
      field name from the temporary table, but since the table didn't exist,
      the field name itself was being used as the value.

      We are now more explicit about the fields being selected and populated.
      We have two lists, and no longer assume both are identical. We also use
      NULL columns for temporary table fields unconditionally.

      Patch by myself and Chris Beaven.


version 0.5.0 (18-May-2010):
    * Initial public release
