Liquibase best practice: one <changeLog> per action, or one <changeLog> per "version"?

Loving Liquibase, use it every single day.  Just a quick question about my way of versioning, whether or not it’s good or not, if there’s any potential downfalls that I’m just not seeing yet.  I’m using the master-file system that is recommended on the Liquibase best practices page.  

When I was setting up and designing our database, I was doing one changeLog per action (createTable, createProcedure, etc. would all get their own commented changeLog).  This was useful for development, since so many changes happened so often.  But now that I’m done with the initial setting up of the database and am ready to roll out, I went back and condensed all the individual changelogs down to only one per schema, with id=“schemaname-1.0.0” since this is the finished version “1”, it’s no longer in development.  This way, when I run “update,” I have one “change” that is commented as “Setup EmployeeManagement schema,” and instead of 60 separate changeLog lines that happen at like 3-5ms, I get one big one that happens in around 400ms or so.

And then going forward as things need to be changed after deployment as either bug fixes or upgrades, I would increment the version numbers as follows:

#.0.0, this far left number would indicate a massive change such as the introduction and changing of multiple tables, multiple stored procedures, etc. all at once.

0.#.0 would indicate an addition of maybe one or two tables, neither a “ton” of stuff, nor just “one” change.

and 0.0.# would be for small single actions, like if I have two spelling mistakes in version 1.0.0, I would fix one in 1.0.1, and then fix the other in 1.0.2.

So far this is solid, I like it, it’s clean, and it makes sense.  I just want to make sure there’s not some disadvantage I’m not seeing yet that has to do with changeLog’s being too long or too many things happening in one changeLog.

My general theory is that you shoudl find what works best for the way you work. I tend to break up changelogs either by version (one changelog per software version) or by component (one changelog for the shopping cart, one for the catalog, etc.). 

Are you moving and combining changeSets over time? Or just talking about how to name/manage the changeLog files?


Thanks for the reply.  Just talking about how to name/manage changeLog files.  So far I haven’t had any problems condensing them down to “per version.”  I was initially worried that if I put like 50 changes into one , it would be a nightmare to figure out where the update fails, should it ever fail.  But so far so good, finally realized I was probably overthinking it :slight_smile:

The one thing I would say is that if you include data insertions as part of your giant changeset, then if there’s a data clash the whole thing will roll back.  Might be a bit inconvenient.