Versioning

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 metadata

  • Version management with Git (history)

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.

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.

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 &gt ;

<?xml version="1.0" encoding="UTF-8"?><v:versions xmlns:v="https://schemas.unitedplanet.de/intrexx/2016/versionmanager/versioninfo/" lock="false">    <v:version guid="83F4893FA60DD288DD89C3240B5CA70B83E0ED7E" major="1" minor="0" patch="0" creationTime="1501153173848">        <v:property name="date">2017-07-26T22:00:00Z</v:property>        <v:property name="minProductVersion">9400</v:property>        <v:property name="additionalRequirements">            <v:text>                <v:item lang="de"/>                <v:item lang="en"/>            </v:text>        </v:property>        <v:property name="description">            <v:text>                <v:item lang="de"/>                <v:item lang="en"/>            </v:text>        </v:property>    </v:version></v:versions>

Replace the property lock="false" with lock="true" and save the file.

<?xml version="1.0" encoding="UTF-8"?><v:versions xmlns:v="https://schemas.unitedplanet.de/intrexx/2016/versionmanager/versioninfo/" lock="true">

Callables

The callables

$Portal.getApplicationVersionInformation("<appGuid>"))
$Portal.getWorkflowVersionInformation("<wfGuid>"))
$Portal.getLayoutVersionInformation("<layoutDirName>"))

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:

$Portal.getApplicationVersionInformation("<GUID der Applikation>").getCurrentVersion().getFormattedVersion()

Click here for more information.

History - Version management with Git

Where can a history be created?

A history can be created in the following modules:

erstellt werden. A Git repository forms the basis for the history. For each respective module, this is created in the following directory:

  • Applications module (Portal directory internal/application/store/<Application GUID>)

  • Processes module (Portal directory internal/workflow/<Process GUID>)

  • Design module (Portal directory internal/layout/xml/layouts/<Layout name>)

angelegt. >) 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.

Here, you can see the dialog that opens when you publish an application. During the versioning process of applications or processes, the scripts they contain are also versioned.

Options

Options / Publishing

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. 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:

Portal properties / Options

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 these settings.

New entry in the history

A new history entry can be created in the following ways:

  • Applications - File menu

    • Publish application

      • Optimized publish with history

      • Complete publish with history

    • Create entry in application history

  • Processes - File menu

    • Publish process with history

    • Create entry in process history

  • Design - File menu

    • Publish layout with history

    • Create entry in layout history

New history entries are also created via user or system actions.

User actions

An entry is created under the following circumstances:

System actions

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:

Where do I find the complete history?

The complete history can be found here:

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.

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:

  • Variable

  • User (QualifiedLoginName) - automatically identified from the User Manager. This is composed of the username and domain.

  • Date

  • Comment (optional)

The name of the tag must be unique, meaning it may only appear 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

History entries can be compared using the dialog which lists the complete history.

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 for the selected file. 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.

Information about current state

You can see which version is currently open in the respective modules in the following places:

External tools

External tools can also be used when versioning with Git, these can be integrated here.

Export and import

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.

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.