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
properties dialog
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:
Portal directory
/internal/application/store/<GUID of the application
/ process / layout>
are available for semantic versioning. This return an object with the type
"de.uplanet.lucy.server.auxiliaries.versionmanager.VCVersionInfo".
"VCVersionInfo" has the following methods:
getVersions(): List<VCVersionItem>
getCurrentVersion(): VCVersionItem
"VCVersionItem" has the following methods:
getMajorVersion(): int
getMinorVersion(): int
getPatchVersion(): int
getPreReleaseVersion(): String
getCustomVersion(): String
getDate(): Date
getMinProductVersion(): String
getAdditionalRequirements(): Map<String, String>
getDescriptions(): Map<String, String>
getFormattedVersion(): String
This means, the current version of an application can be displayed in the browser
using Velocity, for example:
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
dialog
will open where an entry in the history can be created with
Git.
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
Extras menu / Options.
More information about this is available here:
In the Portal menu / Portal properties
under Options,
you can activate the setting that a history entry is always created when
publishing applications, processes and layouts. Click
here
for more information about this setting.
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 create a new entry
in the history, if the corresponding setting is active
in the
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:
In each case, these menus open a
dialog
which contains the list of history entries.
Furthermore, the Applications,
Processes and Design modules
contain a
History tab at the bottom.
The complete history of the current application, process or layout is also
shown here.
2.5. Use tags
History entries
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
Commit.
Tags for the history of applications, processes and layouts can be created
in the
dialog
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:
Name
User (QualifiedLoginName) - automatically identified from the
User Manager.
This is composed of the username and domain.
Date
Comment (optional)
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
contain whitespace.
Rules for tag names can be found
here.
Optionally, each tag can be commented on. If no comment is defined, the comment
stays empty.
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.
Compare
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
dialog
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
following places:
Processes - On the Process tab and
in the
Details dialog
together with the shortened Git ID and date.
Layouts - On the Layout tab and
in the
Details dialog
together with the shortened Git ID and date.
2.8. External tools
External tools can also be used when versioning with Git,
these can be integrated
here.
2.9. Export and import
2.10. Miscellaneous
Applications, processes and layouts can be saved locally using the
File menu.
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.
.gitattributes
This file contains the definitions for line endings for different
file types.
.gitignore
This file contains directories and files that should not be versioned.