Hide Forgot
When we created migration #7 in the Pulp 2.1 branch, we realized that there was already a #7 in the 2.2 branch, so we just renamed it to #11. This turns out to be bad, because the #7 in 2.2 is an important migration (version sort indexing), and users upgrading from 2.1 to 2.2 will not have that migration applied (since they are already at version 7). The quick fix is to shuffle all of the migrations around by renaming them to their appropriate numbers (move #11 to 7, and raise 7-10 up by one in the 2.2 branch). In the long term, we should probably make the migration system more flexible to help us to handle issues like these. It may be possible to lift the restriction that two migrations cannot share the same number, if we store the list of applied migrations rather than storing a number for the migration version.
https://github.com/pulp/pulp_rpm/pull/322
Moving to verified [root@pulp-v2-server ~]# pulp-manage-db Beginning database migrations. Migration package pulp.server.db.migrations is up to date at version 4 Migration package pulp_puppet.plugins.migrations is up to date at version 0 Applying pulp_rpm.migrations version 8 Migration to pulp_rpm.migrations version 8 complete. Applying pulp_rpm.migrations version 9 Migration to pulp_rpm.migrations version 9 complete. Applying pulp_rpm.migrations version 10 Migration to pulp_rpm.migrations version 10 complete. Applying pulp_rpm.migrations version 11 Migration to pulp_rpm.migrations version 11 complete. Applying pulp_rpm.migrations version 12 Migration to pulp_rpm.migrations version 12 complete. Applying pulp_rpm.migrations version 13 Migration to pulp_rpm.migrations version 13 complete. Database migrations complete. Loading content types. Content types loaded. [root@pulp-v2-server ~]#
2.2 released http://repos.fedorapeople.org/repos/pulp/pulp/stable/2.2/