Let’s assume we introduce Liquibase today on version 8.1. Then in a week’s time we need to make a database change on version 7.5, this is done in the Liquibase way and we put Liquibase on the server. What happens if in 3 months time, the client wants to upgrade to version 8.6 - at the moment we roll up and use updateSQL via CommandLine. Would Liquibase be able to handle the whole upgrade from version v7.5 to version 8.6? Or from my understanding, we would still have to do the manual upgrade prior to Liquibase if i am not wrong?
I assume you are referring to the DBMS version. Liquibase does not need to be on the database server. I’d recommend installing liquibase on a centralize application servers, which will need to be able to connect to each of your database servers.
I may not understand your question. If what I provided doesn’t make sense, can you clarify?
1 Like
Apologies I’ve not explained that very well. I am not referencing Liquibase or DBMS version. I am actually talking about our own software versions - It looks like the only way in our scenario we could get to a point of automation, is to Liquibase all our old rollup scripts for upgrades if i am not wrong?
Our scenario is:
Install Liquibase today and so everything for software version 8.1 is on Liquibase
Client on old version needs a service pack which includes a database change, we would have to install Liquibase as the fix on the server, as we shadow our changes into the latest 8.1 version
When Client upgrades in X period of time, to version say 8.3. We would need to Liquibase our historical rollup scripts so we aren’t deploying anything in the way prior to Liquibase.
Is my understand correct?
