I am currently working on a project, where we want to give long-term support (LTS) for some specific "LTS versions" which we will release in the future.
Like the name says, we want to give support (bug fixes/patches) for this LTS versions over a longer period of time, without forcing the customer to update to the newest version. Each customer has his own local database.
Now the problem is, what if a patch of a LTS version contains database migrations? Is there any good pattern/guideline/best practice how to handle this situation?
We use a migration-driven database delivery approach similar to what is described here: https://enterprisecraftsmanship.com/2015/08/18/state-vs-migration-driven-database-delivery/
Example The first LTS version "v1" with migration "M1" has been released and install for customer "A". The last recent release is "v2.3" with migration "M16" Now a patchversion "v1.0.1" is necessary with a migration "X" (which f.e. changes the type of a column from int to bigint).
The problem The customer has installed "v1.0.1" and now wants to update to a newer version. One idea is, that he only can update to a version which contains migration "X", so that the code is compatible with the data base. But there is still following problem:
At the time when migration "M2" was written, migration "X" didn't exists. What if it (or some of the following migrations) is not compatible with the changes done by migration "X"?
