Versions

How schema versioning works

A schema version is a read-only snapshot of everything in a schema at one moment. You create versions by hand, at the milestones that matter to you. Every script Kenseme generates for deployment starts from a version, so versions are also how your design reaches a real database.

[screenshot]
The Schema Versions page with three version cards, newest first, each showing a change summary.

What a version captures

When you create a version, Kenseme copies the current state of the schema:

  • The schema’s name, description, database schema name, and default dialect.
  • Every table with its columns, indexes, and relationships.
  • Every view, stored procedure, function, and script, with their output columns, parameters, and the SQL body for each dialect you have written.
  • Every enum and its values.

Your live schema keeps changing after that. The version does not. You can open it, compare it, and generate SQL from it, but you cannot edit it.

Note: Environments, attribute values, and glossary links are not part of a version. They stay attached to the live schema.

When versions are created

Versions are created manually. Saving a table or editing a view never creates one on its own.

Kenseme creates a version automatically in one case: when you roll the whole schema back, it can take a pre-rollback snapshot first so the rollback can be undone. See Roll back to an earlier version.

Create a version

In the app: Data Model › Schemas › your schema › Versions › Create Version

You can also use Create Version in the VERSIONING card on the schema’s Info tab.

  1. Click Create Version. Kenseme compares the schema with the latest version while the dialog shows Analyzing schema changes....
  2. Read the change summary. It lists what changed since the latest version, for example 3 columns (2 added, 0 removed, 1 modified). The first version of a schema says This will be the first version for this schema.
  3. Check the yellow warning, if one appears. It lists views, procedures, or functions that have no script in the schema’s default dialect. Those objects are left out of any script you generate for that dialect. The list is also appended to the version’s notes.
  4. Set the Major, Minor, and Revision numbers. Kenseme suggests 1.0.0 for a first version and a revision bump (for example 1.4.3 after 1.4.2) after that.
  5. Optionally type Notes (optional), up to 4,000 characters.
  6. Click Create Version.

A toast confirms Version 1.4.3 created.

Version numbers

Versions use three numbers, major.minor.revision, shown as v1.4.3. Kenseme only enforces one rule: the new number must be greater than the latest version. If it isn’t, the dialog says Version must be greater than the current latest (1.4.2).

The meaning of each number is up to your team. A common convention:

Bump Use it for
Major Breaking changes: a table removed, a column renamed, a type narrowed.
Minor Additive changes: new tables, columns, or views.
Revision Small fixes: descriptions, defaults, a corrected view body.

What versions let you do

Versions and your real database

A version describes a design. Creating one does not touch any database.

  • To deploy a version, generate a script from it and run that script against your target.
  • Every generated script creates a small tracking table, z_blaze_version, in the target and inserts a row recording the version, the script type, and who generated it. Query it to see which version a database is on.
  • Rolling back in Kenseme changes only the design. To take a database back as well, generate a DOWN migration script and run it.

Tip: Cut a version before every deployment. Then the deployed database always matches a version you can open, compare, and regenerate.