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)
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:
API-incompatible modifications are published
New functions, which are compatible with the current API, are published
Modifications consist of API-compatible bug fixes only
Furthermore, pre-release versions can be stated as an addition to the 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="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">
$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:
getAdditionalRequirements(): Map<String, String>
getDescriptions(): Map<String, 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.
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.
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:
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.
A new history entry can be created in the following ways:
Applications - File menu
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.
An entry is created under the following circumstances:
Every time an application, process or layout is published via the File menu and the setting Always create history entry when publishing applications, workflows or layouts is active. If a repository does not exist yet, this will be created here.
When an application, process or layout is published via the File menu and the setting Create entry in application history is active. The entry is created after publishing. This setting is hidden in the dialog, if the portal property Always create history entry when publishing applications, workflows or layouts is defined.
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:
Activation/Deactivation of a process (User: Current user)
Definition of the default layout (User: Current user)
- User management
publishAllApplications, publishAllProcesses (User: Intrexx)
The complete history can be found here:
For the current application: Application menu / Application history
For the current process: Process menu / Process history
For the current layout: Layout menu / Layout history
In each case, these menus open a dialog which contains the list of history entries.
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:
User (QualifiedLoginName) - automatically identified from the User Manager. This is composed of the username and domain.
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.
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.
You can see which version is currently open in the respective modules in the following places:
External tools can also be used when versioning with Git, these can be integrated here.
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.
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 file types.
This file contains directories and files that should not be versioned.