# Versioning In Eximee each **application element** — e.g. a form, process, script, or content — has its own version history, managed directly in the repository. The versioning mechanism makes it possible to safely introduce changes, track modifications, and easily restore earlier versions when needed. ### **Major and minor versions** The versioning system distinguishes two version levels: * **Major versions** — marked with consecutive integers: `1`, `2`, `3`, etc.\ They are used to denote changes that affect how the application works or its structure (e.g. changes to the data schema, process logic, or relationships between components). * **Minor versions** — 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 **a minor one**. Versioning is done manually — the system does not enforce automatic version number increments. ### **Draft version** When an application element is being edited, its **draft version**is created automatically. A draft version is a temporary copy of the edited element that does not yet affect the application’s operation 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 can be only **one draft version** at a time. * Editing a draft version **locks the branch**, which means that other users cannot make changes to the same major version at the same time. * The lock is removed automatically when the user: * saves the draft as a new `major` or `minor`, * version, or abandons the draft 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 called **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 option 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 1. "Version history" view

In illustration 1 we can see the version history of the request template, which has many major versions. Major version 11.\* has 5 minor versions (from 11.0-11.4). ### Branching off the main branch, including production Branching off the main branch is especially recommended before starting larger changes — such as process redesign, data structure modifications, or the development of new functionalities — that could affect the stability of the running application. The mechanism of branching off the main branch is used to separate a stable version (e.g. production) of an application or request from work on new functionalities. Branching consists of creating a new major version, which provides an independent space for further development.

Figure 2. Separating production and development versions

In practice, this means that version 1.\* (e.g. 1.12) can continue to run in production, while the team works in parallel on version 2.\*, developing it independently until it is ready for deployment. This approach makes it possible to maintain a stable version of the application while also developing the next one, 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 3. Parallel development of version 2.0 while maintaining version 1.*

Branching off the production branch is especially recommended before starting larger changes — such as process redesign, data structure modifications, or the development of new functionalities — that could affect the stability of the running application. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/aplikacja-biznesowa/wersjonowanie.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.