Cross-project version management method based on change package and computer readable medium

Abstract

The invention provides a cross-project version management method based on a change package and a computer readable medium, and relates to the technical field of computers. The method comprises the steps of outputting a change packet definition page based on difference information between two software versions, wherein the change packet definition page comprises an asset tree list of at least one hierarchical node and at least one change state identifier; outputting target asset data of the two software versions under a hierarchical node corresponding to any change state identifier in response to a viewing operation for any change state identifier in the at least one change state identifier; and when it is detected that the merging operation for the target asset data is completed, obtaining a change package corresponding to the two software versions based on the target asset data, and upgrading the software version of the target project based on the change package. According to the method, the difference between the two software versions can be selected according to the actual requirements of a user, the change package is written in, the change package is applied to the software version of the target project, and cross-project synchronous upgrading with finer asset granularity is achieved.

Description

TECHNICAL FIELD

[0001] The present application mainly relates to the technical field of computer technology, and in particular to a cross-project version management method based on change packages and a computer readable medium. BACKGROUND

[0002] Currently, in software development, especially in low-code platforms, project version management and asset change synchronization are basic requirements. In the development mode of low-code platforms, template providers of software assets usually copy the software version of the template project to multiple copy projects and provide them to users in different countries and regions for localization. In the scenario where the user group is large, there are many copy projects, and there are localizations in different regions around the world, version synchronization and upgrade between the template project and its derivative projects become a high-frequency, complex operation that lacks systematic support.

[0003] For example Figure 1 As shown in the figure, the template project A copies the software version Master1.0 to the copy projects B and C and provides them to users in different countries and regions for localization. When the source project (i.e., the template project A) is upgraded from the software version Master1.0 to Master2.0, the copy projects need to be updated synchronously in this case, and accordingly, some problems repaired by the copy projects also need to be updated to the source project or other copy projects. The prior art mainly relies on full version merging (such as Git merge) or manual copying, wherein manual copying is inefficient and has a high error rate, and full version merging has a large workload, especially for some version upgrade scenarios that only need to synchronize a small number of fixes or function enhancements. Full version merging also introduces unnecessary changes, resulting in asset waste and high upgrade costs. SUMMARY

[0004] It would be advantageous to provide a mechanism that alleviates, mitigates or eliminates at least one of the above problems.

[0005] In a first aspect, the present application provides a cross-project version management method based on change packages, comprising:

[0006] outputting a change package definition page based on difference information between two software versions, the change package definition page comprising a list of asset trees of at least one hierarchical node and at least one change status identifier, the display position of the at least one change status identifier being determined according to the difference information, one of the at least one hierarchical node corresponding to one or more assets in a software version, the two software versions being associated with a project;

[0007] in response to a viewing operation on any change status identifier in the at least one change status identifier, outputting target asset data of the two software versions under the hierarchical node corresponding to the any change status identifier.

[0008] when detecting a complete merge operation for the target asset data, obtaining a change package corresponding to the two software versions based on the target asset data;

[0009] upgrading the software version of the target project based on the change package.

[0010] Optionally, before the comparing and analyzing each asset in the asset data file to determine a comparison result corresponding to the reference version and the target version, the method further comprises:

[0011] performing semantic analysis on each asset in the asset data file, and deleting data of a preset type in the asset data file based on a semantic analysis result.

[0012] Optionally, the upgrading the software version of the target project based on the change package comprises:

[0013] when detecting a sharing operation for the change package, copying an identifier of the change package;

[0014] outputting an iteration record page of the target project, the iteration record page comprising an import change package button, the import change package button being configured to trigger display of an import change package window for a software version to be updated;

[0015] inputting the copied identifier of the change package in the import change package window for the software version to be updated;

[0016] obtaining the change package based on the identifier, and merging the change package into the software version to be updated.

[0017] Optionally, the change package is a change package corresponding to a target function, and the change package definition page further comprises an asset search box configured to obtain a keyword related to the target function, and the method further comprises:

[0018] screening associated assets related to the keyword in an asset library;

[0019] determining a starting asset from the associated assets according to a selection operation;

[0020] based on a pre-established asset blood relationship, searching for dependent assets having a blood relationship with the starting asset to obtain a search result;

[0021] displaying a change package recommendation window based on the search result.

[0022] Optionally, the displaying the change package recommendation window in the change package page based on the search result comprises:

[0023] The following one or more of the following is displayed in the change package recommendation window: an identifier of the starting asset, a recommended list including the dependent assets determined based on the search result, and a blood relationship path description.

[0024] Optionally, the dependent assets in the recommended list are displayed by asset type.

[0025] Before the software version of the change package upgrade target project, the method further comprises:

[0026] Based on the pre-established asset blood relationship, the blood relationship is traversed with all assets in the change package as the starting point to determine all assets reached by the change package;

[0027] By comparing the existing assets in the change package with all the reached assets, a verification report is generated and output.

[0028] Optionally, the verification report includes missing assets of the existing assets in the change package compared with all the reached assets, and the verification report is displayed through a visual page, and the visual page further includes a first processing entry for triggering automatic addition of all missing assets to the change package, a second processing entry for manually selecting to add missing assets to the change package, and a third processing entry for triggering a warning ignoring confirmation process to continue.

[0029] Optionally, the method further comprises:

[0030] When a triggering operation for the second processing entry is detected, detailed information of all missing assets and selective addition suggestions are output.

[0031] Optionally, the display form of the target asset data matches the development display form corresponding to the target asset data, and the display form includes a pure text form, a list form, or a key-value pair form.

[0032] In a second aspect, an electronic device is provided. The electronic device includes one or more processors and one or more memories coupled to the one or more processors and storing instructions thereon. When the instructions are executed by the one or more processors alone or collectively, the electronic device performs the method of the first aspect described above.

[0033] In a third aspect, a computer-readable medium is provided. The computer-readable medium stores instructions thereon, which, when executed by at least one processor of an electronic device alone or collectively, cause the electronic device to perform the method of the first aspect described above.

[0034] Compared with the prior art, the application has the following advantages: supporting selection of differential write change package between two software versions combined with actual needs of users, and applying the change package to the software version of the target project, realizing finer asset granularity, and synchronous upgrade across projects. BRIEF DESCRIPTION OF DRAWINGS

[0035] The accompanying drawings are included to provide a further understanding of the application, and are incorporated in and constitute apart of this application, illustrate embodiments of the application, and together with the description serve to explain the principles of the application. In the drawings:

[0036] Figure 1 is a schematic diagram of a cross-project version iteration scenario;

[0037] Figure 2 is an exemplary flowchart of a cross-project version management method based on change package provided by an embodiment of the application;

[0038] Figure 3 is a schematic diagram of a visual page provided by an embodiment of the application;

[0039] Figure 4 is a schematic diagram of another visual page provided by an embodiment of the application;

[0040] Figure 5 is a schematic diagram of still another visual page provided by an embodiment of the application;

[0041] Figure 6 is a schematic diagram of still another visual page provided by an embodiment of the application;

[0042] Figure 7 is a schematic diagram of still another visual page provided by an embodiment of the application;

[0043] Figure 8 is a schematic diagram of still another visual page provided by an embodiment of the application;

[0044] Figure 9 is a schematic diagram of still another visual page provided by an embodiment of the application;

[0045] Figure 10 is a schematic diagram of still another visual page provided by an embodiment of the application;

[0046] Figure 11 is a schematic diagram of still another visual page provided by an embodiment of the application;

[0047] Figure 12 shows a simplified block diagram of an electronic device suitable for implementing exemplary embodiments of the present disclosure. DETAILED DESCRIPTION

[0048] In order to illustrate the technical solutions of the embodiments of the present application more clearly, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description only show some examples or embodiments of the present application, and those skilled in the art can further apply the present application to other similar situations without any creative effort, based on the drawings. The same reference signs in the drawings represent the same structure or operation, unless otherwise clear from the context or otherwise indicated.

[0049] As shown in the present application and claims, unless the context clearly indicates otherwise, the words "one", "an", "a", and / or "the" do not mean "only one", but can include a plurality or more than one, unless the context clearly indicates otherwise. Generally, the terms "comprising" and "including" only indicate including the steps and elements clearly indicated, and these steps and elements do not constitute an exclusive list, and the method or device can further include other steps or elements.

[0050] Unless specifically stated otherwise, the relative arrangement of components and steps, numerical expressions, and numerical values set forth in the examples are not intended to limit the scope of the present application. It should be understood that the dimensions of the various parts shown in the drawings are not necessarily to scale. Techniques, methods, and devices known to those of ordinary skill in the relevant art can not be discussed in detail, but should be considered as part of the description of the present application. In all examples shown and discussed herein, any specific value should be interpreted as merely exemplary, and not as a limitation. Therefore, other examples of the exemplary embodiments can have different values. It should be noted that similar reference signs and letters represent similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further discussed in subsequent drawings.

[0051] Flowcharts are used in the present application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in sequence. Instead, various steps can be processed in reverse order or simultaneously. Meanwhile, other operations can be added to or removed from these processes, or one or more steps of operations can be removed from these processes.

[0052] In order to better understand the present application, some terms related to the present application are explained as follows:

[0053] Target version: The version that needs to apply the change package and perform the merge operation, usually the iteration version in the copy project. It can also be understood as the version to be operated, for example, when defining a change package from version Master1.0 to Master2.0, Master2.0 is the target version. Reference version: The source version that provides the difference content, the change content will be migrated from this version to the target version. It can also be understood as the reference or version that needs to be merged, for example, when defining a change package from version Master1.0 to Master2.0, Master1.0 is the reference version.

[0054] Difference comparison: Compare the asset content between two software versions, identify changes, conflicts, additions, deletions, and movements.

[0055] Merge: The process of integrating the difference content in the reference version into the target version, supporting automatic merging and manual confirmation.

[0056] Baseline version: The initial version relied on when the project is copied or created, serving as a reference for difference merging and upgrade judgment.

[0057] Change status identification: In the visualization page (such as the change package definition page, etc.), visually mark the change type of the asset (such as: change, conflict, handled, addition, deletion, movement, etc.).

[0058] Change: There is a difference between the reference version and the current version (target version) when comparing, and the baseline version and one version are the same, and the other version is different when merging.

[0059] Conflict: Refers to incompatible modifications to the same asset in the reference version and the current version (target version) during the merging process, which requires manual handling. For example, for the same asset, the reference version, the current version (target version), and the baseline version are different, and the same asset is confirmed as a conflict.

[0060] Move: The location of the current version node is inconsistent with the reference version.

[0061] Merge failure: Due to identification conflicts, system abnormalities, and other reasons, the merge may fail, and the abnormal reason can be viewed by hovering.

[0062] Handled: The handled content is the change range of the change package, and assets not marked as handled will not be included in the change package.

[0063] Asset granularity: The smallest unit of change identification and operation control, such as pages, components, variables, data models, etc.

[0064] Change transparently: When the child node (such as the second-level node) has differences, the parent node (such as the first-level node) will use the colorless "." to prompt the differences of the child node. For example, the yellow "." indicates that there is a change, and the red "." indicates a conflict or change;

[0065] Add and delete: The addition or deletion of difference assets (i.e. difference information) between two software versions is expressed through gray-out and strikeout. For example: any asset exists in the reference version but not in the current version (target version), the hierarchical node corresponding to the asset will be grayed out in the change package definition page. Any asset exists in the current version (target version), but is deleted due to merging operations, the hierarchical node corresponding to the asset will display a strikeout.

[0066] Low-code development (Low-Code Development) is a software development method for rapid application construction, and its core features are:

[0067] Visual modeling: Replace traditional code writing with graphical interfaces (such as drag-and-drop components, flowchart design) to visually express business logic and interface layout;

[0068] Preset modular components: Provide reusable standardized functional modules (such as forms, reports, API interfaces), and developers integrate functions through configuration rather than coding;

[0069] Model-driven logic: Based on data models and business rules, automatically generate underlying code frameworks through declarative configuration (such as parameter setting, rule engine);

[0070] Small amount of code extension: Allow developers to supplement complex logic through scripts or custom components, but the code volume is less than 20% of traditional development mode.

[0071] Existing low-code platforms often use the whole project merging strategy (such as Git merge) when dealing with engineering version differences, which does not support independent extraction and controllable upgrade of local changes, resulting in the need to perform full merging when only a small part of bug fixes or function enhancements need to be synchronized, which is time-consuming and prone to unnecessary changes. In addition, for the scenario where a template provider copies the software version of a template project to multiple copy projects and provides them to users in different countries and regions for localization, changes between sub-projects (i.e. copy projects) cannot be directly synchronized, and only manual offline operations or code export and import between different projects can be used to share patch content or function upgrades, which is a high cost of repeated development and difficult to ensure version consistency.

[0072] To alleviate at least one of the above problems, the present application proposes a cross-engine version management method based on change package, which supports selecting difference between two software versions to write change package according to actual user demand, and applying the change package to the software version of the target engine, so as to realize finer-grained, cross-engine synchronous upgrade.

[0073] Referring to Figure 2 The embodiment of the present application proposes a cross-engine version management method based on change package, which is applied to a version management system. The version management system can be run by an electronic device, which can be a server or a terminal device. For example, but not limited to, the terminal device can include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over Internet Protocol (VoIP) phone, a wireless local loop phone, a tablet computer, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, a wireless endpoint, a mobile station, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a smart device, a wireless customer premises equipment (CPE), an Internet of Things (Iot) device, an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or an automation processing chain context), a consumer electronics device, a relay node, a device operating on a business and / or a private wireless network, etc. The cross-engine version management method based on change package includes:

[0074] S20: output a change package definition page based on difference information between two software versions, the change package definition page including an asset tree list of at least one hierarchical node and at least one change state identifier. The display position of the at least one change state identifier is determined according to the difference information, and one of the at least one hierarchical node corresponds to one or more assets in the software version. Wherein, the two software versions include a reference version and a target version, and are associated with an engine.

[0075] In one embodiment, the above-mentioned two software versions can belong to the same engine. For example, Figure 1 As shown in the scenario, when a source engine (i.e., template engine A) is upgraded from software version Master1.0 to Master2.0 by pulling out a branch, the user wants to synchronize some changes from software version Master1.0 to Master2.0 to other copy engines. For this scenario, software versions Master1.0 and Master2.0 are the two software versions in S20, and both belong to the same engine A.

[0076] In another embodiment, the above-mentioned two software versions can also belong to different engines. For example, Figure 1As an example, assume that a software version Master2.0 is copied from an external project to project A, and the user wants to synchronize some changes from Master1.0 to Master2.0 to other copy projects. In this scenario, the software versions Master1.0 and Master2.0 are two software versions in S20, and they belong to different projects.

[0077] In an embodiment, before performing step S20, the following steps can also be included:

[0078] Step 1: Select two software versions (i.e., the reference version and the target version) in step S20.

[0079] Step 2: Obtain and compare the difference of the asset data files of the two software versions to determine the difference information of the two software versions.

[0080] For example, referring to Figures 3-5 , the application scenario is that the user wants to merge the difference in the software version "S12-070" in project A to the software version "S12-069" in the same project, and write the merged content from the software version "S12-070" to the software version "S12-069" into a change package. For this scenario, the version management system can output Figure 3 the iteration record page about project A, the user touches the "create change package" button corresponding to "S12-069", the corresponding version management system determines the software version "S12-069" as the target version, and the page jumps to Figure 4 the create change package configuration page, the user selects the project internal version "S12-070" as the reference version in the page, inputs the change package name "bg1", and touches the "confirm" button. Further, the version management system generates a copy of the target version for merging differences, and compares the differences of the asset data files of the software version "S12-070" and the software version "S12-069" to determine the difference information of the two software versions, and displays Figure 5 the change package definition page about "bg1". The change package definition page includes an asset tree list, which includes hierarchical nodes such as pages, order print pages, services, custom components, etc. The page is a first-level hierarchical node, the order print page under the page is a second-level hierarchical node, the hierarchical node "page" corresponds to the assets related to the page in the software version, and the order print page corresponds to the assets related to the order print page in the software version. The change package definition page also includes different change state identifiers (such as Figure 5 changes and moves) to identify different types of differences between the software version "S12-069" and the software version "S12-070" in the same asset.

[0081] As a feasible implementation, the process of determining the difference information of the two software versions by comparing the asset data files of the two software versions can include: comparing and analyzing each asset according to the data type of each asset in the asset data file, and determining the difference information of the two software versions under different asset types based on the comparison result. The data type includes one or more of the following: text file, JSON file, fixed structure JSON, and the asset data file can be a JSON format data file.

[0082] In one embodiment, when the data type is a text file, the comparison and analysis can be performed by the Git Diff3 algorithm to determine the comparison result of the reference version and the target version under the asset of the text file. When the data type is a JSON file (such as some descriptive information), the comparison result of the reference version and the target version under the asset of the JSON file can be determined by comparing whether the attribute values of each asset are consistent. When the data type is a fixed structure JSON (such as a structure type JSON with multiple components nested under a page), the comparison result can be determined by recursively calling the comparison method.

[0083] For example, the process of recursively calling the comparison method can include: collecting all keys (Key) of the fixed structure JSON in the asset data files of the iteration version, the target version and the baseline version, traversing each key, obtaining the value (i.e. Value) corresponding to each key, monitoring the value change of each key in the three versions, and determining the comparison result based on the value change. The value change includes: "no change on both sides" representing that the target version and the iteration version have no change relative to the baseline version, "only reference version change" representing that only the reference version has changed relative to the baseline version, and "only target version change" representing that only the target version has changed relative to the baseline version.

[0084] S21: In response to a viewing operation on any change state identifier in the at least one change state identifier, outputting the target asset data of the two software versions under the hierarchical node corresponding to the any change state identifier.

[0085] S22: When detecting a complete merging operation on the target asset data, obtaining a change package corresponding to the two software versions based on the target asset data.

[0086] In one embodiment, the target asset data includes first asset data and second asset data of the two software versions under a same change hierarchical node, and the process of obtaining a change package corresponding to the two software versions based on the target asset data includes: writing the difference between the first asset data and the second asset data into the change package. The change hierarchical node refers to the hierarchical node corresponding to the change state identifier.

[0087] For example,Figures 3-5 In the example, software version "S12-069" is the target version and software version "S12-070" is the reference version. Continue to refer to... Figure 6 Users can view Figure 5 When viewing the change package definition page, you can intuitively understand what type of changes have occurred in the two versions under the same asset through different change status indicators. Figure 6 The current version is a copy of software version "S12-069". When a user touches the "Order Print Page" node, the target asset data for both software versions under the "Order Print Page" is displayed, including the first asset data in area 60 and the second asset data in area 61. The user can review and verify whether the differences between the two software versions "S12-069" and "S12-070" under the "Order Print Page" need to be merged into "S12-070". If so, the user can click... Figure 6 The "Complete Merging" button in the system indicates that the version control system has detected the completion of the merge operation. The differences between the first and second asset data are then written into the change package. The difference is that the "Order Print Page - Button - Content" is changed from Button 1 to Button 2. Subsequent projects can use this change package for rapid upgrades and iterations. Furthermore, the change status indicator for the hierarchical node "Order Print Page" is changed from "Changed" to "Processed".

[0088] Alternatively, in another implementation, the target asset data includes first asset data and second asset data for two software versions under all the same change hierarchy nodes. The process of obtaining the change package corresponding to the two software versions based on the target asset data includes: writing the differences between the first asset data and second asset data of the two software versions under all the same change hierarchy nodes into the change package. This can be understood as writing all the difference information between the two software versions in step S20 into the change package at once.

[0089] For example, accept Figures 3-6 For example, software version "S12-069" is the target version and software version "S12-070" is the reference version. Users can view... Figure 5When the change package definition page is displayed, the user can intuitively understand which type of change has occurred between the two versions under the same asset through different change state identifiers, and click different hierarchical nodes to view the specific asset data (i.e., the first asset data and the second asset data) of the two versions under the same hierarchical node. When the user traverses the specific asset data of the two versions under all change state identifiers and wants to write all the changes into the change package, the user can touch the "automatic merging" button in the change package definition page. The version management system confirms that the complete merging operation is detected for the target asset data (i.e., the first asset data and the second asset data of the two software versions under all the same change hierarchical nodes), writes the differences between the first asset data and the second asset data under all the same change hierarchical nodes into the change package, and applies the change package to other projects for rapid upgrade and iteration. In addition, the change state identifiers corresponding to all the change hierarchical nodes are adjusted from "change" to "processed".

[0090] S23: Upgrading the software version of the target project based on the change package.

[0091] In one embodiment, step S23 comprises:

[0092] S230: When a sharing operation for the change package is detected, copying the identifier of the change package.

[0093] S231: Outputting an iteration record page of the target project, the iteration record page including an import change package button, the import change package button being used to trigger display of an import change package window for the software version to be updated,

[0094] S232: Inputting the copied identifier of the change package in the import change package window for the software version to be updated;

[0095] S233: Obtaining the change package based on the identifier and merging the change package into the software version to be updated of the target project, to complete the upgrade of the software version to be updated. The unique identifier of the change package is used to realize efficient and secure synchronization of change content between different projects.

[0096] By way of example, in the example of the above Figures 3-6 , after the user writes the differences between the target version "S12-069" and the reference version "S12-070" into the change package "bg1" through a series of operations, the user can touch "save" in Figure 5 to submit the change package "bg1". Continuing to refer to Figures 7-10 , after the user submits the change package "bg1", the version management system updates the corresponding change package record in the iteration record of the target version "S12-069" in the project A, as shown in Figure 7As shown, a new record for change package "bg1" has been added to the change package history. Touching the "Share" button confirms the sharing operation for change package "bg1" in the version control system, and displays... Figure 8 The page shown is for sharing change packages. This page allows you to copy the identifier of the change package "bg1". When a user wants to import the change package "bg1" into any target project, they can do so through the version control system. Figure 9 The iteration record page of the target project shown displays an import change package window for the software version "S22-400" to be updated, triggered by the "Import Change Package" button on the iteration record page. Figure 10 As shown in the image, enter the identifier of the copied change package in the import change package window, and click "Confirm". The version management system will obtain the change package "bg1" based on the identifier and merge the change package "bg1" into version "S22-400".

[0097] In software development, a feature may involve multiple assets. When a user wants to define a change package related to the target feature, they can do so on the change package definition page (e.g., ...). Figure 5 In this process, users manually select and write the differences of assets related to the target function into the change package by touching the hierarchical nodes in the asset tree list, based on their own experience or memory. Change packages generated in this way are very prone to omitting assets related to the target function.

[0098] To mitigate the aforementioned shortcomings, in one embodiment, assuming the change package corresponds to the target function, the change package definition page also includes an asset search box for obtaining keywords related to the target function. The method further includes: filtering related assets in the asset library; determining the starting asset from the related assets based on the selection operation; searching for dependent assets related to the starting asset based on pre-established asset lineage relationships; obtaining search results; and displaying a change package recommendation window based on the search results. After viewing the displayed change package recommendation window, the user can quickly understand which assets are related to the target function before executing steps S21-S23. Utilizing asset lineage relationships for intelligent recommendations greatly improves the efficiency and accuracy of user filtering and constructing change packages, especially when making function changes involving multiple assets (such as printing, submitting, and querying), where the advantages are particularly evident.

[0099] For example, suppose the target function is "order printing," which involves modifying the printing template. This requires writing all differences between the two versions of all assets (e.g., variables, logic, services, pages, etc.) related to this function into a single change package. Users first need to find a core asset explicitly related to the "printing" function as a starting point, typically a page or a service. The workflow includes: Figure 5The keyword "print" or "printing" is input in the asset search box 50 of the change package definition page, all associated assets whose names or descriptions contain the keyword are searched and returned in the asset library, the user knows explicitly that the print function on the order detail page is to be modified, therefore the user can select the "order printing page" as the starting asset from all the returned associated assets, accordingly, the version management system can add a "join change package" button at the "order printing page" level node of the change package definition page. When the user clicks the "join change package" button, the version management system searches for dependent assets having blood relationship with the starting asset "order printing page" based on the pre-established asset blood relationship, and displays the search result in the change package recommendation window. The search result can be shown in Table 1, for example, which shows all dependent assets having direct and indirect dependency relationship with the starting asset "order printing page". That is, through the asset blood relationship, the user is assisted to automatically find all 6 assets closely related to the starting asset "order printing page", reducing omissions.

[0100] Table 1

[0101] In an embodiment, the following one or more of the starting asset identifier, the recommendation list and the blood path description are displayed in the change package recommendation window, the recommendation list including dependent assets determined based on the search result. The starting asset identifier can be the name of the starting asset, for example "order printing page", which explicitly informs the user that the starting asset analyzed is "order printing page". The blood path description means that each recommended associated asset is marked with the reason for being recommended, for example, being called by the starting asset "order printing page".

[0102] In an embodiment, the dependent assets in the recommendation list are displayed in groups according to asset types, which can include pages, services, logics, variables and data models. For example, taking the starting asset "order printing page" as an example, all dependent assets shown in Table 1 can be displayed in groups according to asset types such as pages, services, logics, variables and data models in the corresponding recommendation list. Alternatively, in another embodiment, each dependent asset displayed in the recommendation list can also be displayed through a dependency chain, for example, for assets indirectly dependent on the starting asset "order printing page" (such as "order data model" dependent on the asset "order query service"), the version management system displays their dependency relationship in an indented or tree structure, so that the user can see at a glance. Alternatively, in yet another embodiment, the recommendation list can display the search result shown in Table 1 in table form. The present application does not make specific limitations on the display form of the content in the recommendation list.

[0103] In one embodiment, before performing the step S23, the integrity of the change package can also be verified, and after the verification is passed, the step S23 is triggered to perform the upgrade of the software version of the target project based on the change package whose integrity verification is passed.

[0104] In one embodiment, the integrity verification of the change package includes: taking all assets in the change package as a starting point, performing blood relationship traversal based on the pre-established blood relationship of the assets, determining all assets reached by the change package, and comparing the existing assets in the change package with all the reached assets to generate and output a verification report.

[0105] For example, assuming that the existing assets of the change package include four assets: order print page, handlePrintLogic, order print service, and order query service. The process of the version management system taking all assets in the change package as a starting point and performing blood relationship traversal based on the pre-established blood relationship of the assets is as follows:

[0106] 1. Find the dependent assets of the order print page: handlePrintLogic, printTemplateVariable, and order print service.

[0107] 2. Find the dependent assets of handlePrintLogic: order print service.

[0108] 3. Find the dependent assets of the order print service: order query service and printConfigVariable.

[0109] 4. Find the dependent assets of the order query service: order data model.

[0110] All the finally reached assets include seven assets: order print page, handlePrintLogic, order print service, order query service, printTemplateVariable, printConfigVariable, and order data model. By comparing the existing assets in the change package with all the reached assets, it is found that the missing assets in the existing assets in the change package compared with all the reached assets include printTemplateVariable, printConfigVariable, and order data model, and a verification report including the missing assets is generated and displayed.

[0111] In one embodiment, the verification report is displayed through a visualization page. Besides displaying the verification report, the visualization page also includes a first processing entry point for triggering the automatic addition of all missing assets to the change package, a second processing entry point for manually selecting missing assets to add to the change package, and a third processing entry point for triggering the process to continue ignoring warnings. These three processing entry points essentially provide the user with three optional processing methods: the first processing entry point allows the user to directly add all missing assets to the change package automatically; the second processing entry point allows the user to select which missing assets to add to the change package from all missing assets; and the third processing entry point allows the user to continue the process directly without adding any missing assets to the change package.

[0112] In one embodiment, when a triggered operation targeting the second processing entry is detected, detailed information on all missing assets and selective addition suggestions are output to assist the user in making a decision to add the corresponding missing assets to the change package. For example, selective addition suggestions may be as shown in Table 2.

[0113] Table 2

[0114] People who develop software using low-code platforms typically don't need to master the relevant software development technologies to complete the project, resulting in a lower technical barrier. Traditional version control tools (such as Git) primarily display plain text or code-level asset data when defining change packages. For developers using low-code platforms, it's difficult to understand their meaning due to a lack of understanding of the underlying software development technologies (such as code comprehension).

[0115] To alleviate the above problems, in one embodiment, the display format of the target asset data in step S20 matches the corresponding developed display format of the target asset data. This display format includes plain text, list format, or key-value pair format. For example, if a developer develops an order printing page using low-code, the developed display format of that page would be as follows: Figure 11 As shown, the button's component attributes are displayed in key-value pair format. Accordingly, in this embodiment, when executing step S20 and displaying the target asset data under the hierarchical node "Order Print Page," the display format of the button's corresponding component attributes is the same as the corresponding development display format, such as... Figure 6 As shown in the figure. This application provides a visualization capability compatible with low-code assets. Since the display format of the target asset data matches its display format during development when defining a change package, developers can more intuitively understand the differences between versions, which helps them to complete the change package definition more quickly.

[0116] In an embodiment, before performing the difference comparison on the asset data files of the two software versions respectively to determine the difference information of the two software versions, the method further comprises: performing semantic analysis on each asset in the asset data file, and deleting preset type data in the asset data file based on a result of the semantic analysis. The preset type data is invalid comparison data that is pre-entered, such as data representing the display state of an asset. For example, data A is folded in the reference version, and data A is unfolded in the target version. The folding or unfolding of data A has no effect on the version running result. If the invalid comparison data is not removed, on the one hand, the amount of data for subsequent comparison and analysis processing will be larger, and on the other hand, the introduction of the invalid comparison data will also increase the time and effort of the user for manually verifying the comparison or merging result. Based on this, before formal comparison and analysis, the embodiment of the application first removes the invalid comparison data that has no effect on resource running through semantic analysis, which is beneficial to reducing the human resources caused by invalid comparison.

[0117] Figure 12 is a simplified block diagram of an electronic device suitable for implementing embodiments of the present disclosure. For example, the software asset management method described above can be implemented by the electronic device. As shown, the electronic device includes one or more processors 120, one or more memories 121 coupled to the processors 120, and one or more communication modules 122 coupled to the processors 120.

[0118] The communication module 122 is configured for bidirectional communication. The communication module 122 has at least one antenna to facilitate communication. The communication interface can represent any interface necessary for communication with other network elements.

[0119] The processor 120 can be of any type suitable to the local technical network and can include, by way of non-limiting example, one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multi-core processor architectures, as non-limiting examples. The electronic device can have multiple processors such as, for example, a master integrated circuit chip that is time-synchronized with a slave integrated circuit chip.

[0120] The memory 121 can include one or more non-transitory memories and one or more volatile memories. Examples of non-transitory memories include, but are not limited to, read only memories (ROM) 1210, electrically programmable read only memories (EPROM), flash memories, hard disks, compact disks (CD), digital video disks (DVD), and other magnetic storage and / or optical memories. Examples of volatile memories include, but are not limited to, random access memories (RAM) 1211 and other volatile memories that do not persist for durations longer than the duration of the power.

[0121] The computer program 123 includes computer-executable instructions that are executed by the associated processor 120. The program 123 can be stored in the ROM 1210. The processor 120 can perform any appropriate action and processing by loading the program 123 into the RAM 1211.

[0122] Embodiments of the present disclosure can be implemented by the program 123 so that the electronic device can perform any of the processes of the disclosed Figure 1 Embodiments of the present disclosure can also be implemented by hardware or by a combination of software and hardware.

[0123] In some embodiments, the program 123 can be tangibly embodied in a computer-readable medium, which can be included in the electronic device (e.g., the memory 121) or other storage device accessible by the electronic device. The electronic device can load the program 123 from the computer-readable medium into the RAM 1211 for execution. The computer-readable medium can include any type of tangible non-transitory memory, such as ROM, EPROM, flash memory, a hard disk, a CD-ROM, a DVD, and the like. The program 123 is stored on the computer-readable medium.

[0124] In general, the various embodiments of the present disclosure can be implemented in hardware or special-purpose circuits, software, logic or any combination thereof. Some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software which can be executed by a controller, microprocessor or other electronic device. While various aspects of an embodiment of the present disclosure are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein can be implemented in, as non-limiting examples, hardware, software, firmware, special-purpose circuits or logic, general purpose hardware or controller or other electronics, or some combination thereof.

[0125] The present disclosure also provides at least one computer program product which is tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, executed by devices on a target real or virtual processor to perform the methods described above with reference to the Figure 2 In general, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules can be combined or split between program modules as desired. Machine-executable instructions for program modules can be executed within the local or distributed device. In a distributed device, program modules can be located in both local and remote storage media.

[0126] Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor of the computer or other programmable data processing apparatus, enables the functions / operations specified in the flowchart diagrams and / or block diagrams to be implemented. The program code can be retrieved from the storage by a retrieval program (for example, loader) and

[0127] In the context of the present disclosure, the computer program code or related data can be carried by any suitable carrier and means enabling a device, apparatus, or processor to perform the various processes and operations as described above. Examples of carriers include signals, computer readable media, and the like.

[0128] The computer readable medium can be a computer readable signal medium or a computer readable storage medium. The computer readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0129] Further, although operations are described as being in a particular order, this should not be understood as requiring that particular order or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Likewise, while a number of specific implementation details are contained in the above discussion, these should not be construed as limiting the scope of the disclosure, but merely as being descriptive of particular embodiments thereof. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0130] While the present disclosure has been described with reference to specific implementations thereof, it will be understood that variations and modifications will occur to those skilled in the art. Therefore, it is intended that the appended claims shall cover all such variations and modifications that come within the scope of the disclosure.

Claims

1. A method for cross-project version management based on change packages, characterized in that, The method includes: A change package definition page is output based on the difference information between two software versions. The change package definition page includes an asset tree list of at least one hierarchical node and at least one change status identifier. The display position of the at least one change status identifier is determined according to the difference information. One of the hierarchical nodes corresponds to one or more assets in the software version. The two software versions are associated with the project. In response to a view operation on any of the at least one change status identifiers, the target asset data of the two software versions under the corresponding hierarchical node of the change status identifier is output. When the completion of the merge operation for the target asset data is detected, the change package corresponding to the two software versions is obtained based on the target asset data; The software version of the target project is upgraded based on the aforementioned change package.

2. The method as described in claim 1, characterized in that, The upgrade of the target project's software version based on the change package includes: When a sharing operation for the change package is detected, the identifier of the change package is copied; Output the iteration record page of the target project. The iteration record page includes an "Import Change Package" button, which is used to trigger the display of an "Import Change Package" window for the software version to be updated. In the import change package window for the software version to be updated, enter the identifier of the copied change package; The change package is obtained based on the identifier, and the change package is merged into the software version to be updated.

3. The method as described in claim 1, characterized in that, The change package is the change package corresponding to the target function. The change package definition page also includes an asset search box for obtaining keywords related to the target function. The method further includes: Filter related assets in the asset pool that are associated with the keywords; The starting asset is determined from the associated assets based on the selection operation; Based on the pre-established asset lineage, search for dependent assets that are related to the starting asset to obtain the search results; Based on the search results, a change package recommendation window will be displayed.

4. The method as described in claim 3, characterized in that, Based on the search results, a change package recommendation window is displayed on the change package page, including: The change package recommendation window displays one or more of the following: the identifier of the starting asset, a recommendation list, and a lineage path description, wherein the recommendation list includes dependent assets determined based on the search results.

5. The method as described in claim 4, characterized in that, The dependent assets in the recommended list are displayed in groups by asset type.

6. The method as described in claim 3, characterized in that, Before upgrading the software version of the target project based on the change package, the method further includes: Starting with all assets in the change package, a lineage traversal is performed based on pre-established asset lineage relationships to determine all assets reached by the change package; Compare the existing assets in the change package with all the assets that have been reached, and generate and output a verification report.

7. The method as described in claim 6, characterized in that, The verification report includes the missing assets of the existing assets in the change package compared to all the assets reached. The verification report is displayed through a visualization page, which also includes a first processing entry for triggering the automatic addition of all missing assets to the change package, a second processing entry for manually selecting to add missing assets to the change package, and a third processing entry for triggering the ignore warning confirmation process to continue.

8. The method as described in claim 7, characterized in that, The method further includes: When a triggered operation is detected targeting the second processing entry, output detailed information on all missing assets and suggestions for selective addition.

9. The method according to any one of claims 1-8, characterized in that, The display format of the target asset data matches the development display format corresponding to the target asset data. The display format includes plain text, list format, or key-value pair format.

10. A computer-readable medium storing computer program code that, when executed by a processor, implements the method as claimed in any one of claims 1-9.

Images