Release oriented changesets (including SNAPSHOT)

General Discussion
1

Hi,

I want to organize the app changesets per app versions, similar with what is described in Best Practices.
So, the general idea is to have a single root/master changelog file that contains only ‘include’ version changelog files (changelog-1.0, changelog-2.0, …changelog-version.xml).
Now, using diffChangelog liguibase command (via liguibase gradle) I compare the PostgreSQL database with Hibernate database.
The resulted (new) changesets are add in the current app version changelog file.
The problem is that until I release a new version I have a SNAPSHOT version => use changelog-snapshot.xml file.
I want in the release process to “promote” the snapshot changelog to a release (1.0 for example) changelog.
The perfect approach is to create a new changelog-1.0.xml file and to move all the changesets from changelog-snapshot.xml file to changelog-1.0.xml.

Of course this approach doesn’t work now because in the databasechangelog table we have the changelog-snapshot.xml as value in the ‘filename’ column and this value is part of the checksum calculation algorithm.
Probably for the end user of the application it is not a problem because it only uses the stable versions, but for development and test instances it is a problem.

If possible, I would like a changelog file for each version (major or minor) not just per major version.

I don’t know if logicalFilePath can help me somehow.
The transition with snapshot changelog is somehow useful because it is simple for the developer to understand (snapshot → release cycle). On the other hand, you as a developer don’t know what the next version will be (if it will be a major one or a minor one or maybe a fix) and in this situation you don’t know in advance in which file to write/generate the new chnagesets (the added since the last release)

I’m curious what you think about this approach, if anyone uses it.
On the other hand, I would like to know what other variants you recommend for changesets organization, and if they solve the problem I described.

Thanks!

2

In the end, I will use the behavior described above but in each version changelog file (including changelog-snapshot.xml) I will add a logicalFilePath that points to the master/root changelog file.
The value saved by Liquibase for the filename column of the databasechangelog table will be the same (‘db/changelog/changelog-master.xml’ in our case) for all changesets.
The only downside I can see is that we cannot identify the real changelog file for a changeset but I think that it’s not so important because we can do it via search files (‘grep’ command for example).
Also, the author value for each changeset will be the same (a ‘virtual’ user). So, the author and filename are fixed, for each changeset the same value, we will identify a changeset only by id.

Do you see any problems with the described solution?

3

From a dev’s point of view the filename column of the databasechangelog table is not so important, as I said I can find the changeset via id (the id is generated in such a way that it is unique) but I wonder if I’m not missing something else. I don’t know for example if this information (the value stored in the filename column) is used by other Liquibase components (commands, tools, …).
Can someone add an answer/clarification?