Thanks for your answer Steve. I am not quite sure if it was a good idea,
but in order to allow "rebasing" in the future, we did
something like this.
base version x ( typical
liquibase usage ). Base version x is always the same
x
---> x + 1 ---> x + 2
base version y (
"rebasing" pattern). Base version y can be changed, and
start creating upgrade scripts from a new base version at any time.
Scenario A)
y
---> y + 1 ---> y + 2
(our db scripts went out of hand and are too long to run, or just
inefficient, we decide
to clean y + 2 scripts a little bit, and start from scratch again, but
also allowing to upgrade all the way
from y to y + 4. This results in two different paths. One in which
you started from y or y + 1 all the way to y +2, and a different one
in which you started from y + 2)
Scenario B)
y + 2 ---> y + 3
---> y + 4
In order to support this kind of scenarios, which we don't do
often, we have y + 2 changesets which share the id, author and have
logicalFilenamePath set to a predefined value, so they look the same.
No matter which path you took, liquibase will know if the changeset
for y + 2 has been run or not by lookin at his databasechangelog.
The down side is that you can't have the changesets from both
scenario A and B combined in the same top level changelog, since y +2
changesets will cause a duplicate identifiers validation error.
There is an easy fix for this, just removing y + 2 upgrade
changesets from the build, but at the cost of losing one shot upgrades
from release y, or y + 1 all the way to y + 4.
I hope my explanation makes sense, it is somewhat difficult to
explain without graphics.
Many thanks for your answer again