Labels vs. contexts in 3.3.0

I added for some additional background.

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.


Yes, at a high level that is what they both do.

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.


While I understand the gist behind labels and contexts, I’d like to hear about the use cases that caused this feature to exist.

Also, are they documented on the main site? I’m not sure where I can put labels in my changesets.

Thanks very much,



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)?



Hi, this link is broken. Is the content moved elsewhere ?

Note: I have read the official documentation but I was looking for a more detailed comparison

Sorry about that @evantill, looks like it got moved here:

1 Like