On 09/11/2013 09:12 AM, Alex Huang wrote:
As for separating db version from release version. In general I agree with that. Again, it's a practical thing. Currently, cloudstack db changes with every release so even if you separate them basically they just advance in a parallel path anyways. I don't see any time soon where cloudstack db schema will stabilize to a point where there's just code changes without schema changes. When we see that happening, we should break apart the schema from the release version.
I'd have to disagree. First, in a maintenance release, why are you changing the scheme to begin with? But, if you do, you can do the following. Say 4.1 was schema 42 and 4.2 in now schema version 50. If you do a 4.1.1 release that needs a schema change you change the schema in version 51. And then you install schema 51 on 4.1.
Schemas should always be backwards compatible in that old code should run on new schema. I don't think it is the case today as the presence of "clean up" SQL files seems to indicate you are breaking that approach (but I don't really know).
There's other approaches too. I really don't think we should do too much to continue to enhance our current approach. I'd really prefer we just move to flyway. Regarding hotfixes, here's how flyway can handle it http://flywaydb.org/documentation/faq.html#hot-fixes
I don't have the time at the moment to help move to flyway, so if somebody else does, great. Otherwise I'll get to it eventually.
Darren
