Joget DX 8 Stable Released
The stable release for Joget DX 8 is now available, with a focus on UX and Governance.
These are the instances where versioning is involved with:-
Component | Application Version | Process Version |
---|---|---|
Process | Yes | Yes |
Form | Yes | |
Datalist | Yes | |
Userview | Yes | |
App Properties | Yes |
Important
Each app version may hold more than one process version but one can only start a process instance of the current latest process version the app version is holding.
These are the instances when process version will change.
Creation of new version from existing app version.
The current app version selected will be cloned (process, form, datalist, userview and properties including default plugin properties, message bundles, and environment variables ) over to the next available version number.
Inside an app version, it contains process design but process design has its own set of versioning called process version.
Important
Each process version belongs to only one app version.
Under each process in processes tab, click on "Show Additional Info" link to reveal the Process Definition ID. You can find the process version in between the 2 hashes.
Component | Application Version | Process Version |
---|---|---|
Process | Yes | Yes |
Form | Yes | |
Datalist | Yes | |
Userview | Yes | |
App Properties | Yes |
These are the instances when process version will change.
Process design update via deployment from Process Builder or by uploading .xpdl definition file.
When one of the above takes place, Joget Workflow will find the next available process version and assign to it.
App Version | Process Version | Action Taken |
---|---|---|
1 | 1 | |
1 | 1 -> 2 | Process design update |
For example, in the table above, upon process design update via process builder, the process version will now turn to 2 from 1.
In some cases, one may perform a process design update on older app version even though there's a newer app version in place as illustrated in the table below.
App Version | Process Version | Action Taken |
---|---|---|
1 | 1 | |
1 | 1 -> 3 | Process design update |
2 | 2 |
In this case, app version 1 will now hold process version 3 and not 2.
By updating the process design in the same app version: all existing running process instances in the same app version will automatically be updated to the new process flow in the background. Do not perform this unless it is absolutely necessary in a production server.
Do not repetitively update process design in a short time
Process migration will takes place once process design is changed. Repetitive process change deployment will disrupt existing process instances migration in the background.
By updating the process design in the same app version: all existing running process instances in the same app version will automatically be updated to the new process flow in the background. Do not perform this unless it is absolutely necessary in a production server.
After you update the process design, do remember to check all the activity/plugin mappings to make sure that they are current and in sync with your process design.
Process instance that contains activity mapping(s) make use of the forms created under the same app version. Regardless of the current published app version, the process instance's assignment will show form mapped to it, of the same app version the process instance falls under.
Published Version
Published Version of App does not affect access of forms by process instance.
For example, in the table and screenshot below, 123_hr_expense_process1 will show forms mapped according its activity mapping under app version 1 regardless of whether app version 1 or 2 is published or not.
On the other hand, 124_hr_expense_process1 will show forms from app version 2.
App Version | Process Version | Action Taken |
---|---|---|
1 | 1 | Started a process instance 123_hr_expense_process1 |
2 | 2 | Started a process instance 124_hr_expense_process1 |