Hi all - I’d like to announce / give a prominent heads up that Alembic 0.7.0 is ready for release. Over the past several weeks I’ve completed the initial implementations for two critical features, SQLite migrations and multiple branch/ merge support, as well as merged over a dozen bug fixes and smaller features. This release is probably the most dramatic set of changes Alembic has had since some early refactorings long before Openstack was making use of it, and as such I think it’s appropriate to make sure that this is anticipated.
Given that I’ve seen some grumbling about other projects recently releasing on weekends, assuming no new issues are found, I hope to release Alembic 0.7.0 on Sunday night or Monday. I have run a subset of Openstack related tests as is part of my usual continuous environment, including all of oslo.db (there’s one test fix for oslo.db pending) as well as Neutron’s “neutron.tests.unit.db.test_migration” which if I understand it correctly exercises Alembic considerably. Version 0.7.0 includes a lot of tweaks and enhancements in the usual “autogenerate” category as well as to some operational directives, but most prominently includes multiple branch mode, a series of new commands and some changes to existing commands, as well as “batch mode” which is geared towards SQLite. The SQLite batch mode enhancement exists as a new operational directive and series of behaviors that are optional, so code which doesn’t make explicit use of it will not be exposed to the new code. However the multiple branch/merge support involves a fundamental rewrite of the versioning system from the ground up. It was implemented in such a way that there should be no backwards-compatibility problems of any kind - existing environments, script templates, migration scripts, and alembic_version tables will continue to work in the exact same manner as they did before, in the absence of using the newer branch features which introduces some mild changes to the workflow when used. But the system does run on a new set of algorithms for which the currently supported use case of a “single linear stream of revisions” is the so-called “degenerate” case (an odd term for me to use as I am so not a math person). The release does not yet include two new features that I’d like to get in a subsequent release, maybe even 0.7.1 if things go smoothly, including Ann Kamyshnikova’s foreign key constraint autogeneration feature and a separate autogeneration feature for primary key constraints. To those out there wondering what steps to take, here they are: 1. read about the new features, particularly the branch support, and please let me know of any red flags/concerns you might have over the coming implementation, at http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases and http://alembic.readthedocs.org/en/latest/tutorial.html#working-with-branches. 2. if your project uses Alembic already (I know Neutron does but I’m not sure who else yet), fire up a tox environment and install Alembic from master at https://github.com/zzzeek/alembic/, run the tests and please alert me to any breakages. 3. Keep a lookout for the release, and 4. don’t panic! I’ve really tried to test this to a huge extent and if there are problems, I can fix them quickly. thanks all for reading! 0.7 changelog: http://alembic.readthedocs.org/en/latest/changelog.html#change-0.7.0 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
