Changeset identifiers - best practises - supporting multiple branches

General Discussion
1

Team,

Whilst the liquibase documentation doesn’t enforce / recommend any particular convention for the identifier I’d be interested in other teams experiences on what worked well / didn’t for them and why.

We could generate an identifier ourselves based on the date and a number sequence e.g. YYYYMMDD- although if others merge changesets in the same day they might get conflicts and resolve sequence numbers. I know it doesn’t matter so much even if out of sequence as the key issue is uniqueness however perhaps some schemes are better.

Have others considered adding bug log / story identifiers from their host system into the identifier too e.g. for JIRA such as JIRA-1234-

Also we may have “newer” changes from old service pack branches merged into master for which we’d want to keep the same changeset identifier presumably i.e. it’s the same logical changeset with schema plus data updates in most cases.

Appreciate your thoughts and we can develop this into a guidance page

2

We have found it easier to have identifiers as JIRA tickets with optional -01/-02 etc when necessary. It has worked well for us, furthermore it immediately tells you which ticket the changeset belongs to.

3

For multiple tickets for a change, usually we put the main jira ticket number as id and reference all tickets in comments. That seems to work well for us.

4

Thanks Raj, yes although the changeset comment could be used to reflect that information too. When you span multiple JIRA tickets for a change do you have any pattern? How do you coordinate numbers between them?

Given the insignificance of the identifier actually needing to be sequential I’m wondering if a simple GUID auto generated is even better with the changeset comment reflecting other information e.g. the date it was originally created / JIRA entities and so on. You would never have to worry about whether an identifier was really unique too.