liquibase-update-to-latest.xml contains all changesets starting from 1.4. This makes it hard to find the changes associated with a particular version. The file should be broken into multiple files, one for each version, and the master file should use the "include" feature of liquibase to pull them together.
We could follow the best practice at: http://www.liquibase.org/bestpractices
It is especially important since it would make it easier to delete changesets, which are no longer relevant i.e. for long unsupported versions of OpenMRS. Currently, we are in a situation that we still run a lot of changesets, which enable upgrading from 1.6.x and older. Even though most are skipped due to preconditions, they slow down the initial setup.
The following needs to be done:
- Create 2 new files liquibase-update-to-2.0.xml and liquibase-update-to-2.1.xml in the same location as liquibase-update-to-latest.xml
- Move all changesets in the current liquibase-update-to-latest.xml to liquibase-update-to-2.0.xml excluding any changesets that were added to master since the 2.0 release, in theory to achieve this you can take the contents of the liquibase-update-to-latest.xml file in the 2.0.x branch and paste them in the liquibase-update-to-2.0.xml file.
- Any new changesets that were added to master since the 2.0 release need to be moved to the liquibase-update-to-2.1.xml file.
- Update liquibase-update-to-latest.xml to include the liquibase-update-to-2.0.xml and liquibase-update-to-2.1.xml files with no changesets of its own.
Going forward, we will put all database changesets for a minor version in liquibase-update-to-x.y.xml and include these in the liquibase-update-to-latest.xml file.
- Update the Platform Release Process page to mention that after creating a maintenance branch, one needs to create the new liquibase-update-x.y.xml file for the next minor/major release and include it in the liquibase-update-to-latest.xml file