Versioning

In Intrexx, the various developmental stages of applications, processes and layouts can be versioned in two ways:

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:


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> 
<?xml version="1.0" encoding="UTF-8"?>
<v:versions xmlns:v="http://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">9000100</v:property>
        <v:property name="additionalRequirements">
            <v:text>
                <v:item lang="en"/>
                <v:item lang="en"/>
            </v:text>
        </v:property>
        <v:property name="description">
            <v:text>
                <v:item lang="en"/>
                <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="http://schemas.unitedplanet.de/intrexx/2016/versionmanager/versioninfo/" lock="true">

1.2. 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: "VCVersionItem" has the following methods: This means, the current version of an application can be displayed in the browser using Velocity, for example: 
$Portal.getApplicationVersionInformation("<Application GUID>").getCurrentVersion().getFormattedVersion()

2. History - Version management with Git

2.1 Where can a history be created?

A history can be created in the following modules: A Git repository forms the basis for the history. For each respective module, this is created in the following directory: 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.

2.2 Settings

2.2.1. Options / Publish




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:

2.2.2. 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 this setting.

2.3. New entry in the history

A new history entry can be created in the following ways: New history entries are also created via user or system actions.

2.3.1. User actions

An entry is created under the following circumstances:

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

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

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

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

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.