Version-number-controlled evolution for database changes
Please see docs/index.rst for further documentation. The docs are also available at http://docs.repoze.org/evolution/
- Document / test compatibility with Python 3.2 / 3.3.
- Add support for building docs under tox.
- Add setup.py docs alias (installs Sphinx and dependencies).
- Add setup.py dev alias (installs testing dependencies).
- Added support for continuous integration using tox and jenkins.
- Drop support for Python 2.4 / 2.5.
- Extended ZODBEvolutionManager to allow passing in a proxy for the transaction module, or None (to suppress transactions altogether).
- Separated tests for ZODBEvolutionManager class from those for evolve_to_latest.
- Remove unncessary assignment.
- repoze.evolution no longer attempts to construe implicitly the version of a database for which no version has been set explicitly. Previously, an unversioned database was construed to already be at the software version. The ZODBEvolutionManager performed a write on read, setting the database version to the software when get_db_version() was called. The constructor for ZODBEvolutionManager now accepts an optional argument, initial_db_version, which specificies the version a database should be considered to be if it does not already have a version set. The default value is None. If a database has not already been marked to be at a particular version, get_db_version() will return the initial database version value. If this is None, attempts to call evolve_to_latest() will fail with a ValueError. This represents a backwards incompatible change, as databases for which no initial version is supplied explicitly will now fail to evolve.
- Added new public method, set_db_version() to IEvolutionManager interface.
- 100% test coverage.
- Initial release.