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 enables safe changes, tracking modifications and easily restoring earlier versions when needed.

Major and minor versions

The versioning system distinguishes two levels of versions:

• Major versions (major) – marked by successive integers: 1, 2, 3, etc. They are used to mark changes that affect the application's operation or its structure (e.g. changes to the data schema, process logic, relationships between components).

• Minor versions (minor) – marked as a floating-point 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 or require adjustments of dependent components (e.g. text changes, layout fixes, cosmetic modifications).

The first version of each application element is 1.0.

When saving changes the user decides whether to create a new major version or a minor version. Versioning is done manually – the system does not enforce automatic version number increments.

Working version (draft)

When editing an application element its working version (draft)is created automatically. A working 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 working version:

• For a given major version branch (e.g. 3.*) there can be only one working version at a time.

• Editing the working version locks the branch, which means other users cannot simultaneously make changes on the same major version.

• The lock is released automatically when the user:

  • saves the working version as a new major or minor,

  • or abandons the working version without saving.

The working version allows safe experimentation with changes – only saving (promoting) the version to the repository makes it appear in the history and available for use in applications.

Version history

Each application element has from the interface a tab Version historywhere 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 working version.

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

Illustration 1. "Version History" view

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