In Intrexx, the various developmental stages of applications, processes and layouts
can be versioned in two ways:
Semantic versioning: Assign a textual version number with meta data
Version management with Git (history)
1. Version number
The version number can be created and edited in the
of applications, processes and layouts. It is not created
automatically but manually. This makes it easier to identify the version
in use. This makes it very easy, for example, to check whether
an application, which was downloaded from the
Intrexx Application Store,
is the latest version and whether there is a new version available
in the store.
Open version manager
Opens a dialog
where version numbers can be created and managed.
For semantic versioning,
the version number is composed of three digits: Major, Minor and Patch.
The format is always as follows:
<Major Version>.<Minor Version>.<Patch Version>. Each digit
is incremented as follows:
Major API-incompatible modifications are published
Minor New functions, which are compatible
with the current API, are published
Patch Modifications consist of API-compatible
bug fixes only
Furthermore, pre-release versions can be stated as an addition to the version number.
1.1 Restrict definition of version number
Application, process and layout developers have the ability
to restrict the definition of version numbers by other users.
This is done by opening the file
"version.xml" in a text editor.
The file is found here:
/internal/application/store/<GUID of the application
/ process / layout>
Each entry in the history corresponds to a Commit
in the Git repository. If you publish an application, process or layout via the
File menu, a
will open where an entry in the history can be created with
In the Extras menu/Options,
you can find the settings for publishing applications, processes and layouts
with or without history under each respective module.
The settings control the default behavior when publishing.
Regardless of which option is selected here, the different publishing methods
can also be selected from the respective File menu.
This means that you can publish without a history entry, even though the setting
for publishing with an entry is defined in the
Main menu Extras/Options.
More information about this can be found here:
In the Portal menu / Portal properties
you can activate the setting that a history entry is always created when
publishing applications, processes and layouts. More information about this
setting can be found
2.3. New entry in the history
A new history entry can be created in the following ways:
For certain actions, the system will automatically created a new entry
in the history, if the corresponding setting is active
Portal properties. If a repository
has not been created yet, this will be created here.
Each new entry receives a static English comment with the prefix
"Intrexx:". The user, who is stored
in the history entry, depends on the action (see below).
The following system actions are supported:
can be marked as important using tags; this makes the specific entry easier
to find. A tag is often used to denote a new version. In principle, every entry
which is important to the Development can be marked with a tag.
Intrexx automatically connects with Intrexx version number
to tags in the history. If, for example, a new application version number is created
and the application is then published, a tag with this version number is
created for this
Tags for the history of applications, processes and layouts can be created
which displays the complete history.
Any number of tags
can be added to a history entry. Tags can also be deleted. Every tag
is constructed as follows:
User (QualifiedLoginName) - automatically identified from the
This is composed of the username and domain.
The name of a tag must be unique, meaning it may only occur once per history.
Furthermore, the tag name must conform to Git - for example, it may not
Rules for tag names can be found
Optionally, each tag can be commented on. If no comment is defined, the comment
A tag is created automatically upon publishing, if the
semantic version number has been changed.
The tag name corresponds to the semantic version number
and if necessary, a suffix is added to prevent duplicate entries.
Opens a dialog
where the versions, which should be compared, can be selected.
Additionally, files can be compared using the Files tab.
View file history
Displays the history of the selected file in the same dialog that will be
reloaded. Afterwards, the comparison can be made. The comparison can also be
made via the menu item
Compare with last entry of application history
and Compare with entry of application history.
The currently opened state can also be compared to the last state
of a history entry in the
where the history entry can be created. The same applies to processes and layouts.
2.7 Information about current state
You can see which version is currently open in the respective modules in the
External tools can also be used when versioning with Git,
these can be integrated
2.9. Export and import
Applications, processes and layouts can be saved locally using the
A locally saved application does not contain Git information.
The same applies to locally saved processes and layouts.
If you open a locally saved object in the corresponding module,
you can view the history of the object
if an application, process with the same GUID
or layout with the same directory name has been published on the server.
2.11. Git configuration files
Configuration files are created when a
Git repository is created.
Depending on the object type (application, process, layout), not every
configuration file is required.
This file contains the definitions for line endings for different
This file contains directories and files that should not be versioned.