In the System Development Life Cycle (SDLC), maintenance is always an essential part in which developers should not neglect. System maintenance refers to modifying the system after launching. This action can correct faults, improve performance, and adapt the system to a rapidly changing environment. The company can modify the system by adding a new field or function, implementing a business policy change, and correcting a problem with the current system.
However, system modification often encounters the problem of versioning. The problem of versioning includes data backup, adaptability of the new system, etc. To minimize the problems brought by versioning, this chapter will introduce several cases of versioning in DragOnce platform.
In usual practice, the App version would be named in a standard protocol of X.X.X. Here are some basic definitions.
Bug fixes address specific issues or problems identified in the application. These updates aim to resolve software defects, improve stability, and enhance the overall user experience. Bug fixes typically do not introduce new features but focus on resolving existing issues. They are denoted by incrementing the patch number in the versioning scheme (e.g., from 1.0.1 to 1.0.2).
These updates typically include bug fixes, performance improvements, and minor feature enhancements. They are designed to maintain compatibility with previous versions and ensure a seamless transition for users.
Major updates involve significant changes to the application. This can include introducing new features, revising core functionality, or making architectural adjustments. Major updates may require additional user training or adjustments to existing workflows. It's important to communicate these changes clearly to ensure a smooth transition for users.
Share the latest layout for all records
i.e. When the developer adds a new widget(s) without any settings on visibility into form, after deployment, both new and old record(s) will share the latest form layout.
Keep different layouts separated by a specific time
i.e. When the developer adds a new widget(s) with visibility setting (e.g. submission date < deployment date) into form, the new widget(s) will not be shown in the old record.
Stop displaying the old layout by a specific time
i.e. When the developer adds a new widget(s) and deploys with visibility settings for all/ most of the old widget(s) (e.g. submission date < deployment date), the old widget(s) will not be shown in the new record(s).
Information !
After deployment, the value of the new widget(s) for the old record(s) will not be triggered/ saved in the database automatically until those records have processed action when opening the record(s).
Share the latest workflow for all records
i.e. When the developer adds a new workflow state(s), after deployment, the old record(s) in “Editing” state will go through “Verification” for approval; and the old record(s) in “HR Approval” state will go to the ‘End’ state.
For new submission, it’ll go through all states for approval.
Keep different workflow separated by a specific time
i.e. When the developer deploys a new workflow state combined with the Diverter setting with the condition (e.g. submission date < deployment date), the old record(s) in “Editing” state will skip to “HR Approval”.
For new submission, it’ll go to ‘Verification’ and ‘HR Approval’.
Stop submission for old workflow by a specific time
i.e. When the developer deploys a new workflow state combined with the Diverter setting with the condition after “Start” state, for an old record(s), it’ll go through the existing workflow for approval until the end.
For new submission, it’ll go through for all new states for approval and skip all old states
Share the latest layout for all records
i.e. When the developer adds a new widget(s) into the PDF report, after deployment, both new and old records will share the latest form layout. However, the old record’s PDF file will show an empty value in the new widget(s).
Keep different layouts separated by a specific time
i.e. When the developer adds a new widget(s) into new/ copied PDF report and applies with visibility setting (e.g. submission date < deployment date) on PDF widget in form, the new/ copied PDF report will be shown for a new submission, and it keeps the old layout for the old record(s).
Stop submission for old layout by a specific time
i.e. When the developer adds a new widget(s) into new/ copied PDF report and applies with visibility setting (e.g. submission date < deployment date) on PDF widget in form, the new/ copied PDF report will be shown for a new submission, and it keeps the old layout for the old record(s).
Information !
Widget’s visibility inside PDF is not supported. Developers are required to create a new PDF report to keep both the old and new version.
Delete widget(s) in Form
i.e. When the developer deletes widget(s) in form, the value of the deleted widget(s) in the old record(s) is still kept in the database. However, the deleted widget(s) can’t be selected to show in any table view.
Delete state(s) in workflow
i.e. When the developer deletes state(s) in workflow, the old record(s) being in the deleted state(s) is rolled back to "Saved” state.
Delete widget(s) in PDF report
i.e. When the developer deletes the widget(s) into the PDF report, then those deleted widgets will not be shown in layout. If the developer wants to keep both versions of the PDF report, the developer can apply the amendment on the new/ copied PDF report.
Information !
To delete widget(s) in Form is irreversible.
To delete state(s) in Workflow is irreversible.
To delete widget(s) in a PDF report is reversible because it’s able to map the value with form widget(s) again by dragging new widget(s).
Merge with existing condition logic
i.e. The new condition can be added directly, and the logic will apply to the new record;
The value on old records will not be affected until the widget is triggered again
Cut-off at certain time on existing condition logic
i.e. The new condition can be added directly, and the logic will apply to the new record;
The value on old records will not be affected no matter that the widget is triggered again, if the new conditions are applied with time concept.
(e.g. submission date < deployment date
Cut-off at certain time from other condition logic
i.e. Due to complexity and maintenance issues, new widgets are recommended to be added for new logic checking (widget B) & to concatenate with (widget C) existing checking widget (widget A).
The logic will apply to the new record; The value on old records will not be affected no matter that the widget is triggered again, if the new conditions are applied with time concept.
(e.g. submission date < deployment date)
On DragOnce, if you would like to upgrade a version number from 1.0 to 2.0, you may follow these steps:
Click the version number in the row of your App in Developing Environment
2. In the prompt, you can select the version upgrade mode accordingly.