0.1.0
=====
- Initial release.  Status of features:

- Alembic is used in at least one production 
  environment, but should still be considered 
  ALPHA LEVEL SOFTWARE as of this release,
  particularly in that many features are expected
  to be missing / unimplemented.   Major API
  changes are not anticipated but for the moment
  nothing should be assumed.

  The author asks that you *please* report all
  issues, missing features, workarounds etc.
  to the bugtracker, at 
  https://bitbucket.org/zzzeek/alembic/issues/new .

- Python 3 is supported and has been tested.

- The "Pylons" and "MultiDB" environment templates
  have not been directly tested - these should be 
  considered to be samples to be modified as
  needed.   Multiple database support itself 
  is well tested, however.

- Postgresql and MS SQL Server environments
  have been tested for several weeks in a production
  environment.  In particular, some involved workarounds
  were implemented to allow fully-automated dropping 
  of default- or constraint-holding columns with 
  SQL Server.

- MySQL support has also been implemented to a 
  basic degree, including MySQL's awkward style
  of modifying columns being accommodated.

- Other database environments not included among
  those three have *not* been tested, *at all*.  This
  includes Firebird, Oracle, Sybase.   Adding
  support for these backends should be 
  straightforward.  Please report all missing/
  incorrect behaviors to the bugtracker! Patches
  are welcome here but are optional - please just
  indicate the exact format expected by the target
  database.

- SQLite, as a backend, has almost no support for 
  schema alterations to existing databases.  The author
  would strongly recommend that SQLite not be used in 
  a migration context - just dump your SQLite database
  into an intermediary format, then dump it back
  into a new schema.  For dev environments, the 
  dev installer should be building the whole DB from 
  scratch.  Or just use Postgresql, which is a much
  better database for non-trivial schemas.  
  Requests for full ALTER support on SQLite should be 
  reported to SQLite's bug tracker at 
  http://www.sqlite.org/src/wiki?name=Bug+Reports,
  as Alembic will not be implementing the
  "rename the table to a temptable then copy the 
  data into a new table" workaround.
  Note that Alembic will at some point offer an 
  extensible API so that you can implement commands 
  like this yourself.

- Well-tested directives include add/drop table, add/drop
  column, including support for SQLAlchemy "schema" 
  types which generate additional CHECK 
  constraints, i.e. Boolean, Enum.  Other directives not
  included here have *not* been strongly tested
  in production, i.e. rename table, etc.

- Both "online" and "offline" migrations, the latter
  being generated SQL scripts to hand off to a DBA,
  have been strongly production tested against 
  Postgresql and SQL Server.

- Modify column type, default status, nullable, is
  functional and tested across PG, MSSQL, MySQL,
  but not yet widely tested in production usage.

- Many migrations are still outright missing, i.e.
  create/add sequences, etc.  As a workaround, 
  execute() can be used for those which are missing,
  though posting of tickets for new features/missing
  behaviors is strongly encouraged.

- Autogenerate feature is implemented and has been 
  tested, though only a little bit in a production setting.
  In particular, detection of type and server 
  default changes are optional and are off by default;
  they can also be customized by a callable.
  Both features work but can have surprises particularly
  the disparity between BIT/TINYINT and boolean,
  which hasn't yet been worked around, as well as 
  format changes performed by the database on defaults
  when it reports back.  When enabled, the PG dialect 
  will execute the two defaults to be compared to 
  see if they are equivalent.  Other backends may 
  need to do the same thing.

  The autogenerate feature only generates 
  "candidate" commands which must be hand-tailored 
  in any case, so is still a useful feature and 
  is safe to use.  Please report missing/broken features
  of autogenerate!  This will be a great feature and
  will also improve SQLAlchemy's reflection services.

- Support for non-ASCII table, column and constraint
  names is mostly nonexistent.   This is also a 
  straightforward feature add as SQLAlchemy itself 
  supports unicode identifiers; Alembic itself will 
  likely need fixes to logging, column identification 
  by key, etc. for full support here.

- Support for tables in remote schemas, 
  i.e. "schemaname.tablename", is very poor.   
  Missing "schema" behaviors should be 
  reported as tickets, though in the author's
  experience, migrations typically proceed only
  within the default schema.