# Versioning

In Eximee every **application element** — e.g. a form, process, script, or content — has its own version history, managed directly in the repository. The versioning mechanism allows changes to be introduced safely, modifications to be tracked, and earlier versions to be easily restored when needed.

### **Major and minor versions**

The versioning system distinguishes two version levels:

* **Major versions (major)** — marked with consecutive whole numbers: `1`, `2`, `3`, etc.\
  They are used to indicate changes that affect the application’s operation or its structure (e.g. changes to the data schema, process logic, or relationships between components).
* **Minor versions (minor)** — marked as a decimal number relative to the major version: `1.1`, `1.2`, `1.3`, etc.\
  They are used when introducing smaller changes that do not affect the application interface and do not require adjustments to dependent components (e.g. text changes, layout fixes, cosmetic modifications).

{% hint style="info" %}
**The first version of each application element is `1.0`.**
{% endhint %}

When saving changes, the user decides whether they are creating a **new major version** or **minor**. Versioning is done manually — the system does not enforce automatic version number increments.

### **Draft version**

When an application element is edited, its **draft version**is created automatically. A draft version is a temporary copy of the edited element that does not yet affect the operation of the application and is not visible to other users.

Key rules for working with a draft version:

* For a given **major version branch** (`e.g. 3.*`) there may be only **one draft version** at a given time.
* Editing a draft version **locks the branch**, which means that other users cannot simultaneously make changes to the same major version.
* The lock is removed automatically when the user:
  * saves the draft version as a new `major` or `minor`,
  * or discards the draft version without saving.

The draft version allows safe experimentation with changes — only saving (promoting) the version to the repository makes it available in the history and usable in applications.

### **Version history**

Each application element has a tab available in the interface **Version history**, where the following are visible:

* all approved versions (`1.0`, `1.1`, `2.0` etc.),
* change descriptions (if added when saving),
* author and modification date,
* access to compare content between versions,
* the ability to restore a selected version as a new draft.

This makes it easy to track changes over time and maintain full control over the development of each application element.

<figure><img src="https://2112972046-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FvwL0PUK8Om9flBIeB5Wk%2Fimage.png?alt=media&#x26;token=196271d0-8289-4580-833f-71b9a71669f8" alt=""><figcaption><p align="center"><em><strong>Figure 1.</strong> "Version History" view</em></p></figcaption></figure>

In Figure 1 we can see the version history of the application template, which has many major versions. In major version 11.\* it has 5 minor versions (from 11.0–11.4).

### Cutting off the main branch, including production

Cutting off the main branch is especially recommended before starting major changes — such as process redesign, modification of the data structure, or development of new functionality — that could affect the stability of the running application.

The main-branch cutting mechanism is used to separate a stable version (e.g. production) of an application or request from work on new functionality. Cutting off a branch consists of creating a new major version, which serves as an independent space for further development.

<figure><img src="https://2112972046-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2Fgit-blob-3f6b59d43870cf0b3c2c88d74cbe6a4da73cd4a1%2Fnowa-wersja-g%C5%82%C3%B3wna-tworzenie.png?alt=media" alt=""><figcaption><p align="center"><em><strong>Figure 2.</strong> Separation of production and development versions</em></p></figcaption></figure>

In practice, this means that version 1.\* (e.g. 1.12) can still run in production while the team works in parallel on version 2.\*, developing it independently until it is ready for deployment. This approach allows you to maintain a stable application version and develop the next one at the same time, minimizing the risk of errors and conflicts between changes. If needed, fixes can also be introduced in the production branch without affecting the new version under development.

<figure><img src="https://2112972046-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2Fgit-blob-455436da6166358586c31c400112371307d324b4%2Frownolegle-wersje-glowne.png?alt=media" alt=""><figcaption><p align="center"><em><strong>Figure 3.</strong> Parallel development of version 2.0 while maintaining version 1.*</em></p></figcaption></figure>

Cutting off the production branch is especially recommended before starting major changes — such as process redesign, modification of the data structure, or development of new functionality — that could affect the stability of the running application.