Labels can be added to changeSets the same as contexts.
The concrete use case behind adding labels was a company that is basically trying to get around not using version control branches. They want to label changeSets based on features (instead of creating a branch) and then selectively “merge” those features at execution time.
The idea of giving the deployment team the power to write complex logic is more general than that particular use case, which is why the more generic “label” term was created.
I think contexts would make the most sense in your case because at runtime the description of the environment is just a simple list of the languages you want installed “EN”, “ES”, “EN, ES”, etc.
When in doubt, I usually go with contexts because it will simplify deployment configuration while giving changeSet authors the option to handle complex logic if needed.
Thanks. That’s interesting. Viewed from a really high level, both are ways of dynamically whittling a changelog down at runtime.
My concrete use case is locale-specific changesets. Picture an installation where the guy running Liquibase says, “OK, what language packs do you want?” and he gets an answer. Then depending on the answer, he does something with expressions or whatever that indicates, say, that the Spanish and English language changesets should be run.
Is that a case better suited for contexts (seemingly so)?
