Java.DBUpdate.What are best practices for naming Liquibase changesets?

Here are battle-tested naming practices that reduce conflicts, improve reviews, and make rollbacks/audits sane.

---

Goals of a good changeset name

A changeset identity in Liquibase is effectively:
(id + author + file path)

So good naming must:

• be unique
• be stable forever
• be searchable
• communicate intent

1) Use globally unique, descriptive IDs

Recommended patterns (pick one and standardize)

A) Timestamp + intent (very common in big teams)

• 2026-01-15-1042-create-users-table
• 2026-01-15-1108-add-status-to-orders

✅ Collision-resistant
✅ Sorts naturally
✅ Easy audit trail

B) Ticket ID + intent (best for traceability)

• PAY-1423-add-index-orders-created_at
• CORE-981-drop-legacy-flag

✅ Maps to work items
✅ Great for compliance

C) Domain prefix + sequence + intent (good for modules)

• users-001-create-table
• users-002-add-unique-email
• orders-010-backfill-status

✅ Clear module ownership
⚠️ Requires discipline to avoid clashes

2) Keep author stable and meaningful

Use a team/service identifier, not a person (people leave, names change).

Examples:

• author: payments-team
• author: fin-analytics-service

If you must use individuals, use something stable:

• author: stanley (ok, but less scalable)

---

3) One changeset = one intent

Bad:

• id: update-schema
• id: fixes

Good:

• id: add-not-null-constraint-users-email
• id: create-index-orders_status

This makes:

• review easier
• rollback reasoning possible
• blame/traceability clean

4) Never rename IDs after they land

Once a changeset is merged and applied anywhere:

• do not change id, author, or file location
• that breaks history identity and causes validation issues / drift

Fix mistakes with a new changeset.

5) Prefer “what/why”, not “how”

Good ID:

• add-unique-constraint-users-email

Less good:

• alter-table-users-add-constraint-idx3

The tool already records the SQL; humans need intent.

---

6) Include rollout hints for risky changes

For large tables / backfills, encode intent:

• orders-backfill-status-batch-1
• expand-add-users_status-nullable
• contract-drop-legacy_column

This maps nicely to expand–migrate–contract.

---

7) Be consistent with separators and casing

Pick one:

• kebab-case: add-user-status
• snake_case: add_user_status

Kebab-case tends to read best in PRs.

---

8) Avoid characters that cause tooling pain

Avoid spaces, #, ?, non-ASCII.
Stick to:

• letters, numbers, -, _

---

Example “gold standard” (what I like in big teams)

- changeSet:
    id: PAY-1423-2026-01-15-add-index-orders-created-at
    author: payments-team
    changes:
      - createIndex:
          tableName: orders
          indexName: idx_orders_created_at
          columns:
            - column:
                name: created_at

Interview-ready answer (2 sentences)

Use stable, globally unique changeset IDs that describe intent, typically combining a ticket or timestamp with the change purpose, and keep author stable (often team/service). Never rename applied changesets, keep one intent per changeset, and use consistent casing/separators to reduce conflicts and improve auditability.