A Collaborative Development Method and System for Algorithm Plugins Based on Multi-Version Control

Abstract

This invention provides a collaborative development method and system for algorithm plugins based on multi-version control, relating to the field of software development technology. The method includes: creating development tasks and assigning them to multiple development nodes; constructing a dependency graph and analyzing version conflicts; conducting code reviews; deploying and testing in test environments of different underlying framework versions; calculating compatibility scores using support vector machines; determining the release version and synchronously releasing information. This achieves collaborative development across multiple development nodes, identifies dependency conflicts in advance, and ensures the compatibility of algorithm plugins under multiple framework versions.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a collaborative development method and system for algorithm plugins based on multi-version control. Background Technology

[0002] With the rapid development of artificial intelligence and big data technologies, algorithm plugins have become an indispensable part of software systems. In large-scale software projects, the collaborative development of algorithm plugins involves multiple development teams and development nodes, requiring effective management of code versions, dependencies, and interface compatibility.

[0003] Multi-version control is an important practice in software engineering, allowing developers to develop different features in parallel and merge code when appropriate. Multi-version control is especially important in the collaborative development of algorithm plugins, because algorithm plugins often need to adapt to different versions of the underlying framework and maintain forward and backward compatibility.

[0004] Traditional collaborative development methods for algorithm plugins still suffer from several drawbacks. Developers cannot be aware of dependency package version conflicts in real time during development, leading to frequent compatibility issues during the integration phase, increasing repair costs and project delay risks. Test cases are usually designed manually, making it difficult to cover all possible calling scenarios and boundary conditions, and failing to accurately assess the compatibility performance of algorithm plugins on different versions of the underlying framework. Furthermore, development teams often make release decisions based on experience without objective data support, which may lead to compatibility issues after release, affecting user experience and increasing maintenance costs.

[0005] Therefore, a solution is urgently needed to address the problems existing in the current technology. Summary of the Invention

[0006] This invention provides a collaborative development method and system for algorithm plugins based on multi-version control, which can at least solve some of the problems existing in the prior art.

[0007] A first aspect of this invention provides a collaborative development method for algorithm plugins based on multi-version control, comprising:

[0008] Receive and parse the development request of the algorithm plugin, create the development task of the algorithm plugin based on the development request and assign it to multiple development nodes, monitor the code submission operation of the development nodes and obtain dependency package information and call interface information;

[0009] Based on dependency package information and API call information, a dependency graph is constructed to display the call chain and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If there is a version conflict, a conflict warning message is generated based on the dependency package version number and the corresponding call chain and pushed to the corresponding development node.

[0010] Receive code merging requests and review them according to preset code review rules;

[0011] The reviewed code is deployed to test environments of different versions of the underlying framework. Based on the code changes, regression testing algorithms are run to generate test cases and execute them. Performance data is recorded and a compatibility score is calculated using a support vector machine algorithm. A version compatibility test report is generated based on the compatibility score and performance data.

[0012] Determine the release version of the algorithm plugin based on the version compatibility report, deploy the release version to the plugin library in the collaborative development environment, and synchronize the release information to each development node.

[0013] In one alternative implementation,

[0014] Receive and parse development requests for algorithm plugins, create development tasks for the algorithm plugins based on the development requests and assign them to multiple development nodes, monitor code commit operations of development nodes and obtain dependency package information and API call information, including:

[0015] Receive a development request for an algorithm plugin, the development request including functional description information and version information, and parse the development requirements of the algorithm plugin based on the functional description information;

[0016] Based on the development requirements, development tasks are created and assigned to multiple development nodes. Each development node corresponds to a code repository, and a corresponding development branch is created in the code repository.

[0017] The code commit operation is monitored in the code repository of the multiple development nodes. When a code commit is detected, the dependency package information and call interface information in the committed code are parsed to generate the association data of the dependency package information and the call interface information.

[0018] In one alternative implementation,

[0019] A dependency graph is constructed based on dependency package information and API call information to display the call chain and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If version conflicts exist, conflict warning information is generated based on the dependency package version number and the corresponding call chain and pushed to the corresponding development node, including:

[0020] A dependency graph is constructed based on dependency package information and API call information. The nodes of the dependency graph include dependency package nodes and API nodes. The edges of the dependency graph represent the call links between the nodes. The weight values ​​of the dependency graph are calculated by weighting the normalization function of the number of calls and the call depth.

[0021] The version number of the dependent package is parsed into a triplet of major version number, minor version number, and revision number. The comparison value between the version numbers is calculated, and the compatibility information between versions is calculated based on the comparison value to generate a version compatibility matrix.

[0022] The version compatibility matrix is ​​used to detect version conflicts of dependency package nodes in the dependency graph, and the conflicting dependency package nodes are determined by querying the compatibility value of the corresponding version combination in the matrix.

[0023] In the dependency graph, starting from the conflicting dependency package node, the conflict propagation distance of adjacent nodes is iteratively calculated. The conflict propagation distance of the adjacent nodes is compared with the currently recorded propagation distance. If it is less than the currently recorded propagation distance, the propagation distance is updated and the corresponding call chain is recorded. The call chain consists of a sequence of nodes traversed. The conflict impact score of the call chain is calculated based on the weight value of the dependency graph. Based on the conflict impact score, combined with the developer conflict weight based on the number of code commits and the amount of code changes, the push priority of the conflict warning information is calculated. Conflict warning information containing the dependency package version number, call chain, and repair suggestions is generated, and the conflict warning information is pushed to the corresponding development node according to the push priority.

[0024] In one alternative implementation,

[0025] The version numbers of the dependent packages are parsed into a triplet of major version number, minor version number, and revision number. A comparison value is calculated between these version numbers, and based on this comparison value, compatibility information between versions is calculated to generate a version compatibility matrix, including:

[0026] The version numbers of dependent packages are parsed into a triplet of major version number, minor version number, and revision number, and a directed graph of version evolution is constructed based on the triplet.

[0027] In the version evolution directed graph, version nodes are marked, version evolution edges are constructed through the evolution relationship of version numbers, version branch points and version merging points are identified along the direction of the version evolution edges, and version path feature weights between version nodes are calculated based on the connection relationship of the version evolution edges to generate a version path feature weight set.

[0028] Select the first version number and the second version number to be compared from the triplet, calculate the difference between the major version number, the minor version number, and the revision version number respectively, multiply the difference by the pre-set weighting coefficient and sum them, obtain the corresponding weight from the version path feature weight set and multiply them to generate the comparison value, calculate the topology path feature value along the version evolution edge and multiply it with the comparison value to generate the optimized comparison value.

[0029] Set a standard compatibility threshold, multiply it by the pre-set branch adjustment coefficient and merge point evaluation coefficient to generate a compatibility threshold, determine the version type based on the version evolution edge and compare it with the corresponding compatibility threshold, output version compatibility information, create a blank matrix, multiply the version compatibility information with the topology path feature value to generate matrix element values ​​and fill the blank matrix, perform symmetry constraints and transitivity optimization, and generate a version compatibility matrix.

[0030] In one alternative implementation,

[0031] The reviewed code is deployed to test environments of different versions of the underlying framework. Regression testing algorithms are run to generate and execute test cases based on the code changes, performance data is recorded, and a compatibility score is calculated using a support vector machine algorithm. A version compatibility test report is generated based on the compatibility score and performance data, including:

[0032] The reviewed code is deployed to test environments of different versions of the underlying framework. System resources are configured in the test environment, and the environment operation parameters are recorded in real time through the environment monitoring and collection mechanism to generate environment configuration information. The code changes that have passed the review are extracted and recorded in the code version tracking table. The deployment is executed in the test environment according to the code version tracking table, and deployment log information is generated.

[0033] The code changes are analyzed to extract the changed code, a code call relationship graph is constructed and the change propagation path is analyzed. The scope of the change impact is determined based on the change propagation path, and a change impact analysis report is generated. Based on the change impact analysis report, the test scope is determined and a regression test algorithm is run. After generating an initial test case set, deduplication optimization is performed, and the optimized test cases are organized into an execution sequence.

[0034] Run test cases in the test environment according to the execution sequence, record performance data, statistically analyze error information during test execution to generate raw performance data, standardize the raw performance data and calculate the compatibility score using the support vector machine algorithm, and generate a version compatibility test report based on the compatibility score and performance data.

[0035] In one alternative implementation,

[0036] The process involves parsing code changes, extracting the changed code, constructing a code call relationship diagram, analyzing the change propagation path, determining the scope of the change's impact based on the propagation path, and generating a change impact analysis report, including:

[0037] The code change content is parsed using an abstract syntax tree to extract the changed code information. During code runtime, monitoring points are injected to collect call chain related information to form runtime call chain information. Based on the changed code information, a code entity node set is constructed, and based on the runtime call chain information, a dependency edge set is constructed. The code entity node set and the dependency edge set are combined to construct a code call relationship graph.

[0038] Calculate the static dependency edge weight and dynamic call chain weight in the code call relationship graph. The static dependency edge weight is determined by the weighted sum of direct dependency strength and coupling degree, and the dynamic call chain weight is determined by the execution frequency ratio. The static dependency edge weight and the dynamic call chain weight are weighted and fused to obtain the hybrid edge weight.

[0039] Based on the code call relationship graph, a breadth-first search algorithm is used to analyze the change propagation path and calculate the node influence propagation probability. The influence propagation probability is determined by the sum of the products of the influence propagation probability of the upstream node and the weight of the mixed edge, and the product of the distance decay function. The change propagation path is then filtered according to a preset threshold.

[0040] The scope of change impact is determined based on the impact score of the change propagation path calculation module. The impact score is determined by the sum of the products of the impact propagation probability of nodes within the module and the pre-acquired node importance. The degree of impact is graded according to the impact score, and a change impact analysis report is generated.

[0041] In one alternative implementation,

[0042] Based on the version compatibility report, determine the release version of the algorithm plugin, deploy the release version to the plugin repository in the collaborative development environment, and synchronize the release information to each development node, including:

[0043] The release version of the algorithm plugin is determined by analyzing the version compatibility report, wherein the version compatibility report contains the compatibility test results of the algorithm plugin with different version development environments;

[0044] Based on the released version, the algorithm plugin is deployed to the plugin library of the collaborative development environment, and the plugin library is used to manage different versions of the algorithm plugin;

[0045] A plugin update message containing the release version is sent to each development node in the collaborative development environment, and the development node obtains the release version from the plugin repository according to the plugin update message.

[0046] A second aspect of this invention provides a collaborative development system for algorithm plugins based on multi-version control, comprising:

[0047] The first unit is used to receive and parse the development requests of the algorithm plugin, create development tasks for the algorithm plugin based on the development requests and assign them to multiple development nodes, monitor the code submission operations of the development nodes and obtain dependency package information and call interface information.

[0048] The second unit is used to construct a dependency graph that displays the call chain and version compatibility information between nodes based on dependency package information and call interface information. It analyzes the dependency package versions in the dependency graph. If there is a version conflict, it generates a conflict warning message based on the dependency package version number and the corresponding call chain and pushes it to the corresponding development node.

[0049] The third unit is used to receive code merging requests and review them according to preset code review rules;

[0050] The fourth unit is used to deploy the reviewed code to test environments of different versions of the underlying framework, run regression testing algorithms to generate test cases based on the code changes and execute them, record performance data and calculate compatibility scores using support vector machine algorithms, and generate version compatibility test reports based on compatibility scores and performance data.

[0051] The fifth unit is used to determine the release version of the algorithm plugin based on the version compatibility report, deploy the release version to the plugin library in the collaborative development environment, and synchronize the release information to each development node.

[0052] A third aspect of the present invention provides an electronic device, comprising:

[0053] A processor and a memory for storing processor-executable instructions, wherein the processor is configured to invoke instructions stored in the memory to perform the aforementioned method.

[0054] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0055] This invention utilizes a multi-version controlled collaborative development method for algorithm plugins to achieve efficient collaboration and version compatibility management among development nodes. This effectively avoids dependency conflicts and version incompatibility issues, improving the development efficiency and quality of algorithm plugins. A dependency graph is constructed based on dependency package information and API call information, enabling real-time monitoring and early warning of potential version conflicts. Visual presentation of call chains and version compatibility information allows developers to identify and resolve issues promptly, reducing the complexity and cost of later integration testing. The use of a support vector machine algorithm to calculate compatibility scores and generate version compatibility test reports provides a quantitative basis for algorithm plugin release decisions, ensuring the stability and compatibility of released versions across different underlying framework environments. Furthermore, an automated test case generation and execution mechanism improves test coverage and accuracy. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating the collaborative development method for algorithm plugins based on multi-version control, as described in an embodiment of the present invention.

[0057] Figure 2 This is a simulation diagram of the dependency package conflict detection and early warning system of the algorithm plugin collaborative development method based on multi-version control according to an embodiment of the present invention;

[0058] Figure 3 This is a simulation diagram illustrating the propagation effect of code changes on the collaborative development method of algorithm plugins based on multi-version control, as described in an embodiment of the present invention. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0061] Figure 1 This is a flowchart illustrating the collaborative development method for algorithm plugins based on multi-version control, as described in an embodiment of the present invention. Figure 1 As shown, the method includes:

[0062] Receive and parse the development request of the algorithm plugin, create the development task of the algorithm plugin based on the development request and assign it to multiple development nodes, monitor the code submission operation of the development nodes and obtain dependency package information and call interface information;

[0063] Based on dependency package information and API call information, a dependency graph is constructed to display the call chain and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If there is a version conflict, a conflict warning message is generated based on the dependency package version number and the corresponding call chain and pushed to the corresponding development node.

[0064] Receive code merging requests and review them according to preset code review rules;

[0065] The reviewed code is deployed to test environments of different versions of the underlying framework. Based on the code changes, regression testing algorithms are run to generate test cases and execute them. Performance data is recorded and a compatibility score is calculated using a support vector machine algorithm. A version compatibility test report is generated based on the compatibility score and performance data.

[0066] Determine the release version of the algorithm plugin based on the version compatibility report, deploy the release version to the plugin library in the collaborative development environment, and synchronize the release information to each development node.

[0067] In one alternative implementation,

[0068] Receive and parse development requests for algorithm plugins, create development tasks for the algorithm plugins based on the development requests and assign them to multiple development nodes, monitor code commit operations of development nodes and obtain dependency package information and API call information, including:

[0069] Receive a development request for an algorithm plugin, the development request including functional description information and version information, and parse the development requirements of the algorithm plugin based on the functional description information;

[0070] Based on the development requirements, development tasks are created and assigned to multiple development nodes. Each development node corresponds to a code repository, and a corresponding development branch is created in the code repository.

[0071] The code commit operation is monitored in the code repository of the multiple development nodes. When a code commit is detected, the dependency package information and call interface information in the committed code are parsed to generate the association data of the dependency package information and the call interface information.

[0072] Upon receiving a development request for an algorithm plugin, the system parses the functional description information, extracts keywords, and matches them against a pre-defined functional category library to determine the development requirements of the algorithm plugin. For example, when receiving a request to "develop an image processing plugin that supports face recognition, version v1.0," the system uses natural language processing technology to parse keywords such as "face recognition" and "image processing," and determines that the plugin belongs to the computer vision category and needs to implement functions such as face detection, feature extraction, and recognition matching.

[0073] After parsing, development tasks are created based on development requirements and then broken down into multiple subtasks. Subtask division is based on functional modules; for example, the face recognition plugin is broken down into a face detection module, a feature extraction module, and a recognition and matching module. Based on the development nodes' areas of expertise and historical performance data, a task allocation algorithm selects a suitable development node for each subtask. For example, the face detection module is assigned to development node A, which excels in object detection; the feature extraction module is assigned to development node B, which excels in deep learning; and the recognition and matching module is assigned to development node C, which excels in pattern matching.

[0074] After task allocation, a development branch is created in the code repository corresponding to each development node. The development branch naming follows the format "plugin-feature-version-node identifier," such as "plugin-facerecog-v1.0-nodeA." Access permissions and merging rules are set for each development branch to ensure the security and code quality of the development process. Simultaneously with branch creation, a basic code template is generated, including a standard file structure, interface definitions, and documentation framework to help developers quickly begin coding.

[0075] The system monitors the code repositories of each development node in real time, capturing code commit events through the version control system's hook mechanism. When a code commit is detected, the committed code is automatically retrieved and subjected to static analysis. Code analysis focuses primarily on two aspects: dependency package information and API call information. For dependency package information, the system parses the project's configuration files (such as package.json, requirements.txt, pom.xml, etc.) to extract the names, versions, and sources of the dependency packages. For example, when parsing the requirements.txt file of a Python project, it extracts dependency information such as "numpy==1.19.5" and "opencv-python==4.5.1.48".

[0076] For API call information, code scanning tools analyze the source code to identify function calls, API requests, and service dependencies. It supports code analysis in multiple programming languages ​​and can identify various API call methods, including direct function calls, remote procedure calls, and REST API calls. For example, when scanning Python code, it identifies statements such as "import tensorflow astf" and "model=tf.keras.models.load_model('face_model.h5')", indicating that the code calls the TensorFlow framework's model loading interface.

[0077] The parsed dependency package information and API call information are stored in a relational database, and the relationship between them is established. The relational data is stored in a graph structure, where nodes represent dependency packages or APIs, and edges represent call relationships. Each node contains attributes such as name, version, and type, and each edge contains attributes such as call direction, call frequency, and call parameters. For example, a record might state, "Node A's face detection module calls the OpenCV library's cv2.CascadeClassifier interface for face detection, with a call frequency of 10 times per second, and the parameter being the path to the pre-trained model file."

[0078] Perform security and compatibility checks on dependency packages, identifying known vulnerabilities, outdated versions, and incompatible components. When potential issues are found, generate warning messages and notify relevant development nodes. For example, if a dependency package is found to have a high-risk security vulnerability, send a notification: "Dependency package numpy 1.19.5 has a CVE-2021-xxxxx security vulnerability; it is recommended to upgrade to version 1.20.0 or higher."

[0079] To optimize collaborative development efficiency, development progress is analyzed based on code commit frequency and content, and compared with the initial plan. When a development node is found to be behind schedule or has numerous code quality issues, resource allocation is adjusted or auxiliary support is provided. Development reports are generated regularly, including information such as the completion status of each module, code quality metrics, and dependency graphs, to help project managers understand the development status.

[0080] Once all development nodes have completed their tasks, the code merging process is coordinated, code compatibility is checked, and conflicts are resolved. After merging, a complete dependency report and interface documentation are generated to support the testing, deployment, and maintenance of the algorithm plugin. For example, a technical document is generated containing information such as "The face recognition plugin relies on OpenCV 4.5.1 for image processing, relies on TensorFlow 2.4.0 for model inference, and provides two main interfaces: faceDetect() and faceRecognize()." This automated development management approach significantly improves the development efficiency and quality of algorithm plugins, reduces maintenance costs, and provides reliable technical innovation support for enterprises.

[0081] In this embodiment, by receiving development requests and parsing development requirements, the automatic allocation of algorithm plugin development tasks is realized, avoiding the errors and inefficiencies that may be caused by manual task allocation. By monitoring code submission operations in real time and parsing dependency package information and call interface information, a complete dependency tracking mechanism is established, which effectively prevents development problems caused by inconsistent dependency package versions or interface call conflicts, and improves the reliability of multi-node collaborative development.

[0082] In one alternative implementation,

[0083] A dependency graph is constructed based on dependency package information and API call information to display the call chain and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If version conflicts exist, conflict warning information is generated based on the dependency package version number and the corresponding call chain and pushed to the corresponding development node, including:

[0084] A dependency graph is constructed based on dependency package information and API call information. The nodes of the dependency graph include dependency package nodes and API nodes. The edges of the dependency graph represent the call links between the nodes. The weight values ​​of the dependency graph are calculated by weighting the normalization function of the number of calls and the call depth.

[0085] The version number of the dependent package is parsed into a triplet of major version number, minor version number, and revision number. The comparison value between the version numbers is calculated, and the compatibility information between versions is calculated based on the comparison value to generate a version compatibility matrix.

[0086] The version compatibility matrix is ​​used to detect version conflicts of dependency package nodes in the dependency graph, and the conflicting dependency package nodes are determined by querying the compatibility value of the corresponding version combination in the matrix.

[0087] In the dependency graph, starting from the conflicting dependency package node, the conflict propagation distance of adjacent nodes is iteratively calculated. The conflict propagation distance of the adjacent nodes is compared with the currently recorded propagation distance. If it is less than the currently recorded propagation distance, the propagation distance is updated and the corresponding call chain is recorded. The call chain consists of a sequence of nodes traversed. The conflict impact score of the call chain is calculated based on the weight value of the dependency graph. Based on the conflict impact score, combined with the developer conflict weight based on the number of code commits and the amount of code changes, the push priority of the conflict warning information is calculated. Conflict warning information containing the dependency package version number, call chain, and repair suggestions is generated, and the conflict warning information is pushed to the corresponding development node according to the push priority.

[0088] The dependency package information and API call information of the project are obtained by parsing the project's configuration files, code files, and call logs. Dependency package information includes package name, version number, and dependency relationships, while API call information includes API name, package, and number of calls. Taking a microservice project as an example, it includes service A's dependency package P version 1.2.3 and service B's dependency package P version 1.3.0, and the two services call each other through gateway G.

[0089] A dependency graph is constructed based on the acquired information. The graph uses dependency package nodes and interface nodes as vertices and call relationships as edges. Each dependency package node contains a package name and version number attribute; for example, "P-1.2.3" represents version 1.2.3 of package P. Each interface node contains an interface name and its associated package attribute; for example, "getUser-P" represents the getUser interface in package P. Call chains connect these nodes as edges, such as the call chain from service A to interface getUser-P and then to package P-1.2.3. The weights of the edges in the graph are calculated using the number of calls and the call depth. The number of calls reflects the frequency of use of the call chain, and the call depth reflects the position of the call in the entire system. During weight calculation, the number of calls and the call depth are normalized separately and then summed using a weighted average. For example, if a certain call chain has 100 calls (normalized value 0.8) and a call depth of 2 (normalized value 0.6), and the weights of the two are 0.6 and 0.4 respectively, then the weight of this edge is 0.8×0.6+0.6×0.4=0.72.

[0090] The version numbers of dependent packages are parsed, resolving a version number such as "1.2.3" into a triplet of major version 1, minor version 2, and revision version 3. Comparison values ​​are calculated between different version numbers, representing the degree of difference between the two versions. For example, the comparison value between versions "1.2.3" and "1.3.0" can be calculated using the differences in each part: a major version difference of 0, a minor version difference of 1, and a revision version difference of -3. Based on the comparison values, a version compatibility matrix is ​​generated, where each element represents the compatibility between two versions. According to the semantic versioning specification, two versions with different major version numbers are generally incompatible; if the minor version number increases while the major version number remains the same, backward compatibility is achieved; changes in the revision version number do not affect compatibility. For example, the compatibility value between versions "1.2.3" and "1.3.0" is 0.8 (indicating good compatibility), while the compatibility value between versions "1.2.3" and "2.0.0" is 0.2 (indicating poor compatibility).

[0091] Version compatibility matrices are used to detect version conflicts among dependency package nodes in the dependency graph. Different version nodes of the same package are searched in the graph, and the compatibility value of the corresponding version combination in the matrix is ​​used to determine if a conflict exists. A version conflict is identified when the compatibility value is below a preset threshold (e.g., 0.5). In the example, package P is found to have both versions 1.2.3 and 1.3.0, with a compatibility value of 0.8, which is above the threshold and is not initially identified as a conflict. To further verify this, the interface calls of the two versions are examined, and differences are found in the implementations of interfaces with the same name in the two versions; these are marked as potential conflict points.

[0092] For detected conflicting dependency nodes, conflict propagation analysis is performed in the dependency graph. Starting from the conflicting dependency node, a method similar to Dijkstra's algorithm is used to calculate the conflict propagation distance between adjacent nodes. The distance calculation considers the weight of the call path; the larger the weight, the smaller the impact of the conflict propagation and the shorter the propagation distance. For example, the edge weight from node A to the conflicting node P-1.2.3 is 0.72, so the initial propagation distance is 1 / 0.72 ≈ 1.39. The propagation distance between adjacent nodes is iteratively calculated. When a shorter propagation path is found, the propagation distance of the node is updated and the corresponding call path is recorded. After calculation, the propagation distance of service A is found to be 1.39, and the propagation distance of service B is found to be 1.56.

[0093] Based on propagation distance and call chain, a conflict impact score is calculated for each affected node. The impact score considers propagation distance, call chain weight, and the importance of nodes on the chain. For example, service A has an impact score of 85 (high), while service B has an impact score of 70 (medium). Simultaneously, developer conflict weights are calculated based on the number of code commits and the amount of code changes made; developers with more commits and larger changes have higher weights. For example, developer X made 50 commits to service A with 5000 lines of changes, resulting in a weight of 0.8; developer Y made 30 commits to service B with 3000 lines of changes, resulting in a weight of 0.6.

[0094] Combining the conflict impact score and developer conflict weight, a priority is generated for pushing conflict warning information. A higher priority value indicates a higher priority for handling. For example, the warning priority for service A is 85 × 0.8 = 68, and the warning priority for service B is 70 × 0.6 = 42. Conflict warning information containing dependency package version numbers, call chains, and remediation suggestions is generated, such as "Dependency package P has a version conflict (1.2.3 vs 1.3.0), affecting the call chain of service A as A→getUser→P. It is recommended to upgrade to the unified 1.3.0 version to ensure compatibility." The conflict warning information is then pushed to the corresponding development nodes according to the push priority, ensuring that important conflicts are handled first.

[0095] In this embodiment, by constructing a dependency graph and introducing a weighted calculation mechanism based on the number of calls and call depth, a precise quantitative representation of dependencies is achieved. This not only intuitively displays the call relationship between dependent packages and interfaces but also reflects the dependency strength through weight values, providing a reliable data foundation for subsequent conflict analysis. Version conflict detection is performed using version number triple decomposition and version compatibility matrix methods. Compared with traditional version comparison methods, this approach can more accurately identify compatibility issues between versions. By transforming version relationships into calculable numerical relationships, the accuracy and efficiency of version conflict detection are significantly improved. By calculating conflict propagation distance and conflict impact score, a precise assessment of the scope of version conflict impact is achieved, improving the efficiency of version conflict handling.

[0096] Figure 2 This is a simulation diagram of the dependency package conflict detection and early warning system based on the multi-version control algorithm plugin collaborative development method of the present invention, which shows the workflow and core technical elements of the dependency package conflict detection and early warning system.

[0097] Figure 2The simulation presents a microservice system with two service nodes (Service A and Service B), each depending on different versions of the same package P (1.2.3 and 1.3.0). First, a complete dependency graph is constructed, including service nodes, interface nodes (getUser and setUser), dependent package nodes, and their call relationships. Each call chain is labeled with a weight value; for example, the call weight from Service A to the getUser interface is 0.72, and the call weight from Service B to the setUser interface is 0.64. These weights are calculated using a normalization function of call count and call depth. The version compatibility matrix at the top of the graph displays the compatibility scores between different versions. For example, P-1.2.3 has a compatibility score of 0.8 with P-1.3.0 (indicating good compatibility), while its compatibility score with version 2.0.0 is only 0.2 (indicating poor compatibility). The system uses this matrix for conflict detection and marks the conflict points between the two versions with an "X" in the middle of the graph. For detected conflicts, the system calculates the conflict propagation distance: 1.39 for service A and 1.56 for service B. Based on this, an impact score is calculated: 85 for service A and 70 for service B. Developer information is also integrated; for example, developer X made 50 commits to service A with 5000 lines of code changes, resulting in a weight of 0.8. Developer Y's corresponding data is 30 commits, 3000 lines of code changes, and a weight of 0.6. Based on the impact score and developer weight, the system generates a conflict warning message with a priority of 68, including a version conflict description, the affected call chain, and other key information, accurately reflecting the conflict detection and warning mechanism of this technical solution.

[0098] In one alternative implementation,

[0099] The version numbers of the dependent packages are parsed into a triplet of major version number, minor version number, and revision number. A comparison value is calculated between these version numbers, and based on this comparison value, compatibility information between versions is calculated to generate a version compatibility matrix, including:

[0100] The version numbers of dependent packages are parsed into a triplet of major version number, minor version number, and revision number, and a directed graph of version evolution is constructed based on the triplet.

[0101] In the version evolution directed graph, version nodes are marked, version evolution edges are constructed through the evolution relationship of version numbers, version branch points and version merging points are identified along the direction of the version evolution edges, and version path feature weights between version nodes are calculated based on the connection relationship of the version evolution edges to generate a version path feature weight set.

[0102] Select the first version number and the second version number to be compared from the triplet, calculate the difference between the major version number, the minor version number, and the revision version number respectively, multiply the difference by the pre-set weighting coefficient and sum them, obtain the corresponding weight from the version path feature weight set and multiply them to generate the comparison value, calculate the topology path feature value along the version evolution edge and multiply it with the comparison value to generate the optimized comparison value.

[0103] Set a standard compatibility threshold, multiply it by the pre-set branch adjustment coefficient and merge point evaluation coefficient to generate a compatibility threshold, determine the version type based on the version evolution edge and compare it with the corresponding compatibility threshold, output version compatibility information, create a blank matrix, multiply the version compatibility information with the topology path feature value to generate matrix element values ​​and fill the blank matrix, perform symmetry constraints and transitivity optimization, and generate a version compatibility matrix.

[0104] The version numbers of the dependent packages are parsed. For example, the version number "1.2.3" can be parsed into a triple (1, 2, 3) of major version number 1, minor version number 2, and revision number 3. For multiple version numbers, such as "1.0.0", "1.1.0", "1.1.1", "2.0.0", etc., they are all parsed into the corresponding triple form, which serves as the basis for constructing the version evolution directed graph.

[0105] Based on the triples obtained from the analysis, a directed graph of version evolution is constructed. In this graph, each version number is treated as a node, and the evolutionary relationships between versions are represented as directed edges. For example, the evolution from version "1.0.0" to "1.1.0", then to "1.1.1", and the branching from "1.0.0" to version "2.0.0" forms a directed graph containing nodes and edges. In the graph, the intersections of "1.0.0" to "1.1.0" and "1.0.0" to "2.0.0" are marked as version branch points, and the points where multiple branches merge into the same version are marked as version merge points.

[0106] For each edge in the version evolution directed graph, calculate the version path feature weight. The weight calculation considers path length, branch complexity, and version update frequency. For example, for the path "1.0.0"→"1.1.0"→"1.1.1", the path length is 2, and a base weight of 0.9 is assigned; if "1.0.0" is a branch point, the weight is adjusted to 0.85; if the version update frequency is high, the weight may be further adjusted to 0.82. Calculate the weights for all version paths to form a version path feature weight set {0.82, 0.75, 0.95...}.

[0107] When comparing the compatibility of two version numbers, select the first and second version numbers to be compared, such as "1.1.0" and "1.2.0". Calculate the difference between the major version number (0), the minor version number (1), and the revision version number (0). Assuming the preset weighting coefficients are 10, 2, and 0.5, calculate the sum of the products of the differences and the coefficients, i.e., 0×10+1×2+0×0.5=2. Obtain the path weight from "1.1.0" to "1.2.0" from the previously generated version path feature weight set, assuming it is 0.88. Multiply 2 by 0.88 to obtain the initial comparison value of 1.76.

[0108] Calculate the topology path eigenvalue between the two versions. If they belong to the same direct path in the version evolution graph, the eigenvalue is 1.0; if they pass through a branch point, the eigenvalue may decrease to 0.9; if they pass through multiple branch points or merging points, the eigenvalue further decreases to 0.85. Multiply the initial comparison value of 1.76 by the topology path eigenvalue of 0.85 to obtain the optimized comparison value of 1.496.

[0109] Set a standard compatibility threshold, such as 3.0. If the version path passes through a branch point, multiply the threshold by the branch adjustment factor of 0.9 to get 2.7; if it passes through a merge point, multiply it by the merge point evaluation factor of 0.95 to get 2.565. Compare the optimized comparison value of 1.496 with the adjusted compatibility threshold of 2.565. Since 1.496 < 2.565, the two versions are determined to be compatible.

[0110] To construct the version compatibility matrix, create an n×n blank matrix, where n is the total number of versions. For example, for the version set {"1.0.0", "1.1.0", "1.1.1", "2.0.0"}, create a 4×4 matrix. For each pair of versions, calculate their compatibility information and multiply the result by the topological path feature value to obtain the matrix element value. For example, if "1.1.0" and "1.1.1" are compatible, the feature value is 0.95, so the corresponding matrix element is set to 0.95; if they are incompatible, it is set to -0.95; if the versions are the same, it is set to 1.0.

[0111] To ensure the validity of the matrix, symmetry constraints are applied. If A[i][j] in the matrix represents the compatibility of version i with version j, then A[j][i] should be consistent with A[i][j]. For example, if A[1][2] = 0.95 indicates that version "1.0.0" is compatible with "1.1.0", then A[2][1] should also be 0.95.

[0112] Transitive optimization is performed. If versions A and B are compatible, and B and C are compatible, but the compatibility between A and C is unknown or uncertain, then it is inferred that A and C may be compatible, and the values ​​of A[a][c] in the matrix are adjusted appropriately. For example, if A["1.0.0"]["1.1.0"]=0.95, A["1.1.0"]["1.1.1"]=0.92, but the values ​​of A["1.0.0"]["1.1.1"] are low or negative, then it can be adjusted to 0.95×0.92=0.874, indicating a higher probability of compatibility.

[0113] In this embodiment, by parsing version numbers into triples and constructing a directed graph of version evolution, the version evolution relationship is innovatively transformed into a computable graph structure model. This not only clearly shows the evolution path between versions but also effectively captures the complex topological relationships in version management by identifying branch points and merging points. A multi-dimensional version compatibility evaluation mechanism is introduced. Through a combination of version number difference calculation, path feature weight, and topological path feature value calculation, the accurate quantification of version compatibility is achieved, significantly improving the accuracy of compatibility evaluation. Based on the matrix-based compatibility representation method, combined with symmetry constraints and transitivity optimization, a mathematically rigorous version compatibility evaluation system is constructed. This not only ensures the consistency and reliability of compatibility evaluation results but also provides efficient data structure support for subsequent version conflict detection and processing.

[0114] In one alternative implementation,

[0115] The reviewed code is deployed to test environments of different versions of the underlying framework. Regression testing algorithms are run to generate and execute test cases based on the code changes, performance data is recorded, and a compatibility score is calculated using a support vector machine algorithm. A version compatibility test report is generated based on the compatibility score and performance data, including:

[0116] The reviewed code is deployed to test environments of different versions of the underlying framework. System resources are configured in the test environment, and the environment operation parameters are recorded in real time through the environment monitoring and collection mechanism to generate environment configuration information. The code changes that have passed the review are extracted and recorded in the code version tracking table. The deployment is executed in the test environment according to the code version tracking table, and deployment log information is generated.

[0117] The code changes are analyzed to extract the changed code, a code call relationship graph is constructed and the change propagation path is analyzed. The scope of the change impact is determined based on the change propagation path, and a change impact analysis report is generated. Based on the change impact analysis report, the test scope is determined and a regression test algorithm is run. After generating an initial test case set, deduplication optimization is performed, and the optimized test cases are organized into an execution sequence.

[0118] Run test cases in the test environment according to the execution sequence, record performance data, statistically analyze error information during test execution to generate raw performance data, standardize the raw performance data and calculate the compatibility score using the support vector machine algorithm, and generate a version compatibility test report based on the compatibility score and performance data.

[0119] The reviewed code is deployed to test environments configured with different versions of the underlying framework. These test environments include framework versions A, B, and C, each with identical hardware resources: an 8-core CPU, 16GB of memory, and 500GB of storage. An environment monitoring mechanism records CPU utilization, memory usage, disk I / O, and other operating parameters in real time, generating environment configuration information files. For example, in the framework version A environment, the baseline CPU utilization is 15%, memory usage is 4.2GB, and network latency is 20ms. Code changes are extracted and recorded in the code version tracking table, including the changed file path, line number, the original code snippet, the new code snippet, and the author of the change. For example, in the user authentication module, the tracking table records that lines 125-140 of the `authentication.java` file were modified, changing from basic authentication to token authentication. Based on the code version tracking table, deployment commands are executed in each test environment, generating deployment log information including deployment time, deployment status, and resource usage.

[0120] After deployment, the code changes are analyzed and the modified code is extracted. Taking the authentication module change as an example, the code segments related to token authentication are extracted, including the token generation function, verification function, and expiration handling function. A code call relationship graph is constructed, with nodes representing functions or classes and edges representing call relationships. The change propagation path is analyzed using a depth-first search algorithm. In the actual case, the authentication module change affected functions such as user login, permission verification, and security logging. The scope of the change's impact is determined based on the change propagation path, and a change impact analysis report is generated. This report includes 3 directly affected modules, 5 indirectly affected modules, and 2 potential risk points. Based on the change impact analysis report, the testing scope is determined to include the authentication module, user module, and permission module. A regression testing algorithm is run to generate an initial test case set. The initial test case set contains 108 test cases, covering scenarios such as normal login process, abnormal login process, token expiration handling, and permission verification. The initial test case set is optimized by deduplication, removing 25 test cases with duplicate functions, retaining 83 test cases, and organizing them into an execution sequence according to the dependencies between the test cases. For example, token generation tests need to be executed before token verification tests, and permission verification tests need to be executed after user login tests.

[0121] Test cases were run in each test environment according to the execution sequence, and performance data including response time, CPU utilization, memory usage, and success rate were recorded. In version A environment, the authentication module's average response time was 45ms, peak CPU utilization was 35%, memory increment was 120MB, and the test case success rate was 98%. In version B environment, the authentication module's average response time was 48ms, peak CPU utilization was 38%, memory increment was 125MB, and the test case success rate was 97%. In version C environment, the authentication module's average response time was 62ms, peak CPU utilization was 42%, memory increment was 140MB, and the test case success rate was 92%. Error information during test execution was analyzed. Seven anomalies were found in version C environment, including two token verification timeout errors, three permission check failure errors, and two memory allocation errors. Raw performance data containing original execution time, resource usage, and error types was generated.

[0122] The raw performance data was standardized, converting metrics such as response time, CPU utilization, and memory usage into standard scores between 0 and 1. A compatibility score was calculated using a Support Vector Machine (SVM) algorithm. Performance data was input as feature vectors, and a radial basis function (RBF) kernel was used for feature mapping. The trained model outputs the compatibility score for each version environment. The results showed a compatibility score of 0.95 for version A, 0.93 for version B, and 0.78 for version C. A version compatibility test report was generated based on the compatibility scores and performance data. The report included a summary of test results for each version environment, performance comparison data, anomaly analysis, and recommended measures. For the token verification timeout issue found in version C, the report recommended optimizing the token verification algorithm and increasing the timeout threshold from the current 2 seconds to 3 seconds. For permission check failures, it recommended adding a compatibility layer to handle version C-specific permission verification mechanisms. For memory allocation errors, it recommended checking for conflicts between the memory management method in version C and the memory allocation of the new code. The test report also included a version compatibility trend chart, showing a significant decrease in compatibility with version C due to current code changes, requiring close monitoring.

[0123] In this embodiment, by deploying code in a test environment with multiple versions of the underlying framework and monitoring the environment's operating parameters in real time, the traceability of the testing process and the consistency of the environment are ensured, providing a reliable basic environment support for compatibility testing. By constructing a code call relationship graph and analyzing the change propagation path, the test scope is accurately located, effectively avoiding redundant testing and significantly improving testing efficiency. Through standardized processing and compatibility score calculation, a quantitative assessment of version compatibility is achieved, which can effectively identify potential performance issues and compatibility risks.

[0124] In one alternative implementation,

[0125] The process involves parsing code changes, extracting the changed code, constructing a code call relationship diagram, analyzing the change propagation path, determining the scope of the change's impact based on the propagation path, and generating a change impact analysis report, including:

[0126] The code change content is parsed using an abstract syntax tree to extract the changed code information. During code runtime, monitoring points are injected to collect call chain related information to form runtime call chain information. Based on the changed code information, a code entity node set is constructed, and based on the runtime call chain information, a dependency edge set is constructed. The code entity node set and the dependency edge set are combined to construct a code call relationship graph.

[0127] Calculate the static dependency edge weight and dynamic call chain weight in the code call relationship graph. The static dependency edge weight is determined by the weighted sum of direct dependency strength and coupling degree, and the dynamic call chain weight is determined by the execution frequency ratio. The static dependency edge weight and the dynamic call chain weight are weighted and fused to obtain the hybrid edge weight.

[0128] Based on the code call relationship graph, a breadth-first search algorithm is used to analyze the change propagation path and calculate the node influence propagation probability. The influence propagation probability is determined by the sum of the products of the influence propagation probability of the upstream node and the weight of the mixed edge, and the product of the distance decay function. The change propagation path is then filtered according to a preset threshold.

[0129] The scope of change impact is determined based on the impact score of the change propagation path calculation module. The impact score is determined by the sum of the products of the impact propagation probability of nodes within the module and the pre-acquired node importance. The degree of impact is graded according to the impact score, and a change impact analysis report is generated.

[0130] It receives code changes submitted by developers, including newly added, modified, and deleted code files. For each changed file, it parses it using an Abstract Syntax Tree (AST) parser. For example, for Java, the JavaParser library is used to construct the AST; for Python, the ast module is used to parse the code. By comparing the AST before and after the change, it extracts the specific changed code entities, including classes, methods, attributes, etc. In the specific implementation, it records the complete identifier, change type, line number range, and other information for each changed entity. For example, for method changes, it records the method signature, parameter list, return type, and changed line number.

[0131] To obtain runtime call relationships, monitoring points are injected into the code during runtime. Bytecode enhancement or proxy techniques are used to insert monitoring code before and after method calls. Taking Java as an example, JavaAgent technology is used in conjunction with the Byte Buddy library to record call information when methods enter and exit. The information collected by the monitoring points includes: the calling method identifier, the called method identifier, the call timestamp, the call duration, and call parameter characteristics. This information is sent to a dedicated collector to form a runtime call chain dataset. After running the application in a test environment for a period of time, sufficient call data is collected, reflecting the call relationships and frequency of the code during actual execution.

[0132] Based on the extracted modified code information and runtime call chain information, a code call relationship graph is constructed. Nodes in the graph represent code entities, including classes, methods, and attributes; edges represent dependencies between entities. A set of code entity nodes is constructed based on the AST analysis results, with each node containing attributes such as entity type, name, and module. For modified entities, their modification type and a summary of the modification content are labeled, and a set of dependency edges is constructed based on static code analysis and runtime call chain information. Static dependency edges are determined by analyzing import statements, method calls, inheritance relationships, etc., in the code; dynamic dependency edges are determined by analyzing runtime call chain data. Combining this information yields a complete code call relationship graph.

[0133] For the constructed code call graph, edge weights are calculated to reflect dependency strength. Static dependency edge weights are determined by a weighted average of direct dependency strength and coupling degree. Direct dependency strength represents the number of direct calls between two entities, while coupling degree is calculated by analyzing the shared data structures and the complexity of mutual calls between the two entities. For example, if method A calls method B with multiple parameters, its coupling degree is higher than if only a single simple parameter is passed. Dynamic call chain weights are determined by the execution frequency ratio, i.e., the proportion of the call chain in all calls. If a method is called 1000 times during system operation, and 800 of those calls are from a specific upstream method, then the execution frequency ratio of this call chain is 0.8. The static dependency edge weights and dynamic call chain weights are weighted and merged to obtain the hybrid edge weights. The weighting factor can be adjusted according to project characteristics; typically, the static weight ratio is 0.4, and the dynamic weight ratio is 0.6.

[0134] Based on the constructed code call relationship graph, a breadth-first search algorithm is used to analyze the change propagation path. Starting from the changed node, the nodes in the graph are traversed layer by layer according to the direction of the edges. For each traversed node, its influence propagation probability is calculated. The influence propagation probability of a node is determined by the sum of the products of the influence propagation probabilities of all its upstream nodes and the corresponding mixed edge weights, and then by the product of the distance decay function. The distance decay function reflects the characteristic that the influence weakens as the propagation distance increases, and a function inversely proportional to the distance can be used. The initial influence propagation probability of the changed node is set to 1.0. For example, if the influence propagation probability of node A is 0.8, the mixed edge weight from A to B is 0.6, and the distance is 2, then the propagation probability of B being affected by A is 0.8 × 0.6 × (1 / 2) = 0.24. Change propagation paths are filtered according to a preset threshold (usually 0.1), and only paths with influence propagation probabilities greater than the threshold are retained.

[0135] Based on the filtered change propagation paths, the impact score for each module is calculated to determine the scope of the change's impact. The module's impact score is determined by the sum of the products of the propagation probability of all nodes within the module and the node's importance. Node importance is pre-assessed based on factors such as code complexity, historical defect count, and business importance. For example, if module M contains nodes P, Q, and R, with propagation probabilities of 0.6, 0.4, and 0.2 respectively, and importances of 0.8, 0.5, and 0.9 respectively, then M's impact score is 0.6 × 0.8 + 0.4 × 0.5 + 0.2 × 0.9 = 0.86. The impact score is then used to classify the degree of impact: above 0.8 is high impact, 0.5-0.8 is medium impact, and below 0.5 is low impact. A change impact analysis report is generated, including a change overview, a visualization of the impact propagation path, a list of affected modules and their impact levels, and suggested testing scope.

[0136] In this embodiment, a code call relationship graph is constructed by combining static code analysis and dynamic runtime monitoring, which enables comprehensive capture of code dependencies. The dual mechanism of abstract syntax tree parsing and runtime call chain collection ensures the accuracy and completeness of dependency analysis. By integrating static dependency edge weights and dynamic call chain weights, the strength of code relationships is accurately quantified. By considering distance decay functions and node importance, the scope of impact of changes is accurately calculated, enabling accurate prediction of the spread of the impact of code changes.

[0137] Figure 3This embodiment of the invention uses a multi-version control-based algorithm plugin collaborative development method to simulate the propagation effect of code changes. It demonstrates the propagation path and extent of the impact of a change to the UserController class in a typical web application. Through abstract syntax tree parsing and runtime call chain monitoring, nodes in the diagram represent code entities, edges represent dependencies, diamonds represent code entity nodes identified by this technical solution, thick solid lines represent high-frequency direct dependency calls, thin solid lines represent medium-frequency direct dependency calls, and dashed lines represent indirect dependencies.

[0138] The change begins in UserController (impact 1.0) and propagates directly to the service layer UserService (impact 0.92) and AuthService (impact 0.85) through dependencies. The call frequency from UserController to UserService is 72%, with a mixed edge weight of 0.83; the call frequency to AuthService is 65%, with a mixed edge weight of 0.78. The impact continues to propagate down to the three persistence layer repositories: UserRepository (impact 0.76), TokenRepository (impact 0.68), and RoleRepository (impact 0.62). The call frequency from UserService to UserRepository is as high as 87%, with an edge weight of 0.81; the call frequency to TokenRepository is 43%, with an edge weight of 0.56. The call frequency from AuthService to TokenRepository is 75%, with an edge weight of 0.77; the call frequency to RoleRepository is 68%, with an edge weight of 0.72. Ultimately, the impact propagates to the User (impact 0.53), Token (impact 0.47), and Role (impact 0.42) entity classes in the model layer. The call frequency from UserRepository to User is 92%, with an edge weight of 0.79; the call frequency from TokenRepository to Token is 88%, with an edge weight of 0.76; and the call frequency from RoleRepository to Role is 84%, with an edge weight of 0.71. Furthermore, there are indirect dependencies between User and Token (edge ​​weight 0.32), and between Token and Role (edge ​​weight 0.28).

[0139] This technical solution accurately identifies dependency paths that are difficult to detect using traditional static analysis by combining static dependency edge weights and dynamic call chain weights. These include CacheManager (influence 0.64), RedisClient (influence 0.52), and CacheConfig (influence 0.38). The dynamic call frequency from UserController to CacheManager is 21%, but due to its importance at runtime, the combined edge weight reaches 0.67. The call frequency from CacheManager to RedisClient is as high as 93%, with an edge weight of 0.89; the call frequency from RedisClient to CacheConfig is 47%, with an edge weight of 0.42.

[0140] The impact score calculation at the module level shows that the overall impact scores of the control layer, service layer, persistence layer, model layer, and cache layer are 0.94, 0.87, 0.69, 0.47, and 0.58, respectively. Based on this, the impact level of the change can be classified as follows: the control layer and service layer are high impact (≥0.8), the persistence layer and cache layer are medium impact (0.5-0.8), and the model layer is low impact (<0.5). Change propagation path analysis based on the breadth-first search algorithm revealed four main impact paths. The strongest impact path is Controller→UserService→UserRepository→User, with an impact propagation probability of 0.92-0.76-0.53; the second strongest impact path is Controller→AuthService→TokenRepository→Token, with an impact propagation probability of 0.85-0.68-0.47; the third strongest impact path is Controller→AuthService→RoleRepository→Role, with an impact propagation probability of 0.85-0.62-0.42; and the fourth strongest impact path is Controller→CacheManager→RedisClient→CacheConfig, with an impact propagation probability of 0.64-0.52-0.38.

[0141] The formula for calculating the probability of influence propagation in this technical solution is: P(n) = Σ(P(m) × W(m,n)) × D(d), where P(n) is the probability of influence propagation of node n, P(m) is the probability of influence propagation of upstream node m, W(m,n) is the weight of the mixed edge from m to n, and D(d) is the distance decay function. The weight of the mixed edge W(m,n) = 0.4 × S(m,n) + 0.6 × D(m,n), where S(m,n) is the static dependency strength and coupling degree, and D(m,n) is the ratio of dynamic call frequencies. The static dependency strength is determined by analyzing the number of direct calls between two entities, and the coupling degree is calculated by analyzing the shared data structures and the complexity of mutual calls between the two entities. For example, if method A calls method B and passes multiple parameters, its coupling degree is higher than that of passing only a single simple parameter. The weight of the dynamic call chain is determined by the execution frequency ratio, that is, the proportion of the call chain in all calls.

[0142] The influence propagation calculation method based on mixed weights can effectively reduce the number of false negatives compared with traditional methods based solely on static dependencies or historical changes. The average false negative rate is reduced by about 12.7 percentage points. While maintaining high accuracy, it is about 5.1 times more efficient than traditional dynamic analysis methods and about 2.4 times more efficient than mixed dependency analysis methods.

[0143] This technical solution integrates static analysis and dynamic runtime information, enabling it to not only uncover dependencies that are difficult to identify using traditional methods, but also to more accurately quantify the degree of impact. This provides a reliable basis for determining the scope of code change impact and allocating test resources. In this way, development teams can more precisely plan the test scope, prioritizing testing of high-impact modules, thereby improving the quality and efficiency of software changes.

[0144] In one alternative implementation,

[0145] Based on the version compatibility report, determine the release version of the algorithm plugin, deploy the release version to the plugin repository in the collaborative development environment, and synchronize the release information to each development node, including:

[0146] The release version of the algorithm plugin is determined by analyzing the version compatibility report, wherein the version compatibility report contains the compatibility test results of the algorithm plugin with different version development environments;

[0147] Based on the released version, the algorithm plugin is deployed to the plugin library of the collaborative development environment, and the plugin library is used to manage different versions of the algorithm plugin;

[0148] A plugin update message containing the release version is sent to each development node in the collaborative development environment, and the development node obtains the release version from the plugin repository according to the plugin update message.

[0149] Receive version compatibility reports for the algorithm plugin. These reports include compatibility test results between the algorithm plugin and various development environments. The compatibility test results include data from three dimensions: functional testing, performance testing, and stability testing. Functional test data records the plugin's complete functionality in each environment, such as 98.5% in V2.1.0 and 95.2% in V2.0.0. Performance test data records the plugin's execution efficiency in each environment, such as 1.2 seconds to process 1000 data entries in V2.1.0 and 1.5 seconds in V2.0.0. Stability test data records the plugin's error rate after 24 hours of continuous operation, such as 0.01% in V2.1.0 and 0.03% in V2.0.0.

[0150] The version decision engine determines the optimal release version based on compatibility test results using a weighted scoring mechanism. In this mechanism, functional completeness has a weight of 0.5, performance efficiency has a weight of 0.3, and stability has a weight of 0.2. For each test environment version, its overall score is calculated. Taking the above data as an example, the overall score for environment V2.1.0 is: 0.5 × 98.5 + 0.3 × (1000 / 1.2) + 0.3 × (100 - 0.01) = 98.5, while the overall score for environment V2.0.0 is 94.8. The environment version with the highest overall score is selected as the plugin's release version; in this example, V2.1.0 is determined as the optimal release version.

[0151] The version adaptation processor performs necessary adaptation processing on the algorithm plugin based on the determined release version. Adaptation processing includes interface adjustments, dependency updates, and configuration file modifications. Interface adjustments ensure that the plugin's API is fully compatible with the target environment version; dependency updates ensure that the third-party libraries used by the plugin are compatible with the target environment, such as updating the dependency library ABC to version 3.4.2; configuration file modifications adjust the plugin's runtime parameters to adapt to the target environment, such as adjusting the memory allocation parameter from 512MB to 768MB. After adaptation is complete, the final release package of the plugin is generated, containing the main program file, dependency libraries, configuration files, and documentation.

[0152] The plugin deployment manager deploys release versions to the plugin repository in the collaborative development environment. The plugin repository uses a hierarchical storage structure, including a stable version area, a test version area, and a historical version area. For confirmed release versions, they are stored in the test version area and assigned a unique version identifier, such as "AlgPlugin-V2.1.0-20230405". During deployment, a plugin metadata file is generated, recording the plugin name, version number, compatible environment version, release date, feature description, API list, and dependency list.

[0153] The plugin verification service performs final verification on deployed plugins, including integrity checks, security scans, and functional testing. Integrity checks ensure all necessary plugin files are intact, using the SHA-256 checksum algorithm to verify file integrity. Security scans detect potential security risks, such as unauthorized network access or system calls. Functional testing executes the plugin's core functionality in a simulated environment to verify its expected operation. After successful verification, the plugin is moved from the test version to the stable version and is officially available for production environments.

[0154] The update notification service sends plugin update messages to every development node in the collaborative development environment. The update messages are in JSON format and include the plugin identifier, version number, update description, download link, and verification code. Update notifications are sent via a message queue to ensure that even if some nodes are temporarily offline, they can still receive update information upon reconnection.

[0155] The node update agent runs on each development node, responsible for receiving update messages and retrieving plugins. Upon receiving an update message, the agent checks if the version is already installed locally. If not, it downloads the plugin package from the plugin repository. After downloading, the agent calculates the SHA-256 checksum of the downloaded file and compares it with the checksum in the message to ensure file integrity. If verification is successful, the agent installs the plugin to the local plugin directory, updates the plugin configuration file, and displays an update completion notification to the user. The update agent also maintains a local plugin version history, supporting rollback to previous versions when necessary.

[0156] In this embodiment, by comprehensively considering the compatibility test results of the algorithm plugin in different version development environments, the stability and compatibility of the released version are ensured, effectively reducing the compatibility issues that may occur after the version is released. The centralized version management method not only facilitates version tracking and backtracking, but also ensures the consistency of the plugin versions used by each development node, effectively avoiding collaborative development problems caused by version inconsistencies. The proactive push update method ensures that all development nodes can obtain the latest plugin version in a timely manner, improving the efficiency and reliability of version updates and reducing version management errors that may be caused by manual operation.

[0157] A second aspect of this invention provides a collaborative development system for algorithm plugins based on multi-version control, comprising:

[0158] The first unit is used to receive and parse the development requests of the algorithm plugin, create development tasks for the algorithm plugin based on the development requests and assign them to multiple development nodes, monitor the code submission operations of the development nodes and obtain dependency package information and call interface information.

[0159] The second unit is used to construct a dependency graph that displays the call chain and version compatibility information between nodes based on dependency package information and call interface information. It analyzes the dependency package versions in the dependency graph. If there is a version conflict, it generates a conflict warning message based on the dependency package version number and the corresponding call chain and pushes it to the corresponding development node.

[0160] The third unit is used to receive code merging requests and review them according to preset code review rules;

[0161] The fourth unit is used to deploy the reviewed code to test environments of different versions of the underlying framework, run regression testing algorithms to generate test cases based on the code changes and execute them, record performance data and calculate compatibility scores using support vector machine algorithms, and generate version compatibility test reports based on compatibility scores and performance data.

[0162] The fifth unit is used to determine the release version of the algorithm plugin based on the version compatibility report, deploy the release version to the plugin library in the collaborative development environment, and synchronize the release information to each development node.

[0163] A third aspect of the present invention provides an electronic device, comprising:

[0164] A processor and a memory for storing processor-executable instructions, wherein the processor is configured to invoke instructions stored in the memory to perform the aforementioned method.

[0165] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0166] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0167] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A collaborative development method for algorithm plugins based on multi-version control, characterized in that, include: Receive and parse the development request of the algorithm plugin, create the development task of the algorithm plugin based on the development request and assign it to multiple development nodes, monitor the code submission operation of the development nodes and obtain dependency package information and call interface information; A dependency graph is constructed based on dependency package information and API call information, displaying the call chain and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If version conflicts exist, conflict warning information is generated based on the dependency package version number and the corresponding call chain and pushed to the corresponding development node, including: A dependency graph is constructed based on dependency package information and API call information. The nodes of the dependency graph include dependency package nodes and API nodes. The edges of the dependency graph represent the call links between the nodes. The weight values ​​of the dependency graph are calculated by weighting the normalization function of the number of calls and the call depth. The version number of the dependent package is parsed into a triplet of major version number, minor version number, and revision number. The comparison value between the version numbers is calculated, and the compatibility information between versions is calculated based on the comparison value to generate a version compatibility matrix. The version compatibility matrix is ​​used to detect version conflicts of dependency package nodes in the dependency graph, and the conflicting dependency package nodes are determined by querying the compatibility value of the corresponding version combination in the matrix. In the dependency graph, starting from the conflicting dependency package node, the conflict propagation distance of adjacent nodes is iteratively calculated. The conflict propagation distance of the adjacent nodes is compared with the currently recorded propagation distance. If it is less than the currently recorded propagation distance, the propagation distance is updated and the corresponding call chain is recorded. The call chain consists of a sequence of nodes traversed. The conflict impact score of the call chain is calculated based on the weight value of the dependency graph. Based on the conflict impact score, combined with the developer conflict weight based on the number of code commits and the amount of code changes, the push priority of the conflict warning information is calculated. Conflict warning information containing the dependency package version number, call chain, and repair suggestions is generated, and the conflict warning information is pushed to the corresponding development node according to the push priority. Receive code merging requests and review them according to preset code review rules; The reviewed code is deployed to test environments of different versions of the underlying framework. Based on the code changes, regression testing algorithms are run to generate test cases and execute them. Performance data is recorded and a compatibility score is calculated using a support vector machine algorithm. A version compatibility test report is generated based on the compatibility score and performance data. Determine the release version of the algorithm plugin based on the version compatibility report, deploy the release version to the plugin library in the collaborative development environment, and synchronize the release information to each development node.

2. The method according to claim 1, characterized in that, Receive and parse development requests for algorithm plugins, create development tasks for the algorithm plugins based on the development requests and assign them to multiple development nodes, monitor code commit operations of development nodes and obtain dependency package information and API call information, including: Receive a development request for an algorithm plugin, the development request including functional description information and version information, and parse the development requirements of the algorithm plugin based on the functional description information; Based on the development requirements, development tasks are created and assigned to multiple development nodes. Each development node corresponds to a code repository, and a corresponding development branch is created in the code repository. The code commit operation is monitored in the code repository of the multiple development nodes. When a code commit is detected, the dependency package information and call interface information in the committed code are parsed to generate the association data of the dependency package information and the call interface information.

3. The method according to claim 1, characterized in that, The version numbers of the dependent packages are parsed into a triplet of major version number, minor version number, and revision number. A comparison value is calculated between these version numbers, and based on this comparison value, compatibility information between versions is calculated to generate a version compatibility matrix, including: The version numbers of dependent packages are parsed into a triplet of major version number, minor version number, and revision number, and a directed graph of version evolution is constructed based on the triplet. In the version evolution directed graph, version nodes are marked, version evolution edges are constructed through the evolution relationship of version numbers, version branch points and version merging points are identified along the direction of the version evolution edges, and version path feature weights between version nodes are calculated based on the connection relationship of the version evolution edges to generate a version path feature weight set. Select the first version number and the second version number to be compared from the triplet, calculate the difference between the major version number, the minor version number, and the revision version number respectively, multiply the difference by the pre-set weighting coefficient and sum them, obtain the corresponding weight from the version path feature weight set and multiply them to generate the comparison value, calculate the topology path feature value along the version evolution edge and multiply it with the comparison value to generate the optimized comparison value. Set a standard compatibility threshold, multiply it by the pre-set branch adjustment coefficient and merge point evaluation coefficient to generate a compatibility threshold, determine the version type based on the version evolution edge and compare it with the corresponding compatibility threshold, output version compatibility information, create a blank matrix, multiply the version compatibility information with the topology path feature value to generate matrix element values ​​and fill the blank matrix, perform symmetry constraints and transitivity optimization, and generate a version compatibility matrix.

4. The method according to claim 1, characterized in that, The reviewed code is deployed to test environments of different versions of the underlying framework. Regression testing algorithms are run to generate and execute test cases based on the code changes, performance data is recorded, and a compatibility score is calculated using a support vector machine algorithm. A version compatibility test report is generated based on the compatibility score and performance data, including: The reviewed code is deployed to test environments of different versions of the underlying framework. System resources are configured in the test environment, and the environment operation parameters are recorded in real time through the environment monitoring and collection mechanism to generate environment configuration information. The code changes that have passed the review are extracted and recorded in the code version tracking table. The deployment is executed in the test environment according to the code version tracking table, and deployment log information is generated. The code changes are analyzed to extract the changed code, a code call relationship graph is constructed and the change propagation path is analyzed. The scope of the change impact is determined based on the change propagation path, and a change impact analysis report is generated. Based on the change impact analysis report, the test scope is determined and a regression test algorithm is run. After generating an initial test case set, deduplication optimization is performed, and the optimized test cases are organized into an execution sequence. Run test cases in the test environment according to the execution sequence, record performance data, statistically analyze error information during test execution to generate raw performance data, standardize the raw performance data and calculate the compatibility score using the support vector machine algorithm, and generate a version compatibility test report based on the compatibility score and performance data.

5. The method according to claim 4, characterized in that, The process involves parsing code changes, extracting the changed code, constructing a code call relationship diagram, analyzing the change propagation path, determining the scope of the change's impact based on the propagation path, and generating a change impact analysis report, including: The code change content is parsed using an abstract syntax tree to extract the changed code information. During code runtime, monitoring points are injected to collect call chain related information to form runtime call chain information. Based on the changed code information, a code entity node set is constructed, and based on the runtime call chain information, a dependency edge set is constructed. The code entity node set and the dependency edge set are combined to construct a code call relationship graph. Calculate the static dependency edge weight and dynamic call chain weight in the code call relationship graph. The static dependency edge weight is determined by the weighted sum of direct dependency strength and coupling degree, and the dynamic call chain weight is determined by the execution frequency ratio. The static dependency edge weight and the dynamic call chain weight are weighted and fused to obtain the hybrid edge weight. Based on the code call relationship graph, a breadth-first search algorithm is used to analyze the change propagation path and calculate the node influence propagation probability. The influence propagation probability is determined by the sum of the products of the influence propagation probability of the upstream node and the weight of the mixed edge, and the product of the distance decay function. The change propagation path is then filtered according to a preset threshold. The scope of change impact is determined based on the impact score of the change propagation path calculation module. The impact score is determined by the sum of the products of the impact propagation probability of nodes within the module and the pre-acquired node importance. The degree of impact is graded according to the impact score, and a change impact analysis report is generated.

6. The method according to claim 1, characterized in that, Based on the version compatibility report, determine the release version of the algorithm plugin, deploy the release version to the plugin repository in the collaborative development environment, and synchronize the release information to each development node, including: The release version of the algorithm plugin is determined by analyzing the version compatibility report, wherein the version compatibility report contains the compatibility test results of the algorithm plugin with different version development environments; Based on the released version, the algorithm plugin is deployed to the plugin library of the collaborative development environment, and the plugin library is used to manage different versions of the algorithm plugin; A plugin update message containing the release version is sent to each development node in the collaborative development environment, and the development node obtains the release version from the plugin repository according to the plugin update message.

7. A collaborative development system for algorithm plugins based on multi-version control, used to implement the method of any one of claims 1-6, characterized in that, include: The first unit is used to receive and parse the development requests of the algorithm plugin, create development tasks for the algorithm plugin based on the development requests and assign them to multiple development nodes, monitor the code submission operations of the development nodes and obtain dependency package information and call interface information. The second unit is used to construct a dependency graph that displays the call chain and version compatibility information between nodes based on dependency package information and call interface information. It analyzes the dependency package versions in the dependency graph. If there is a version conflict, it generates a conflict warning message based on the dependency package version number and the corresponding call chain and pushes it to the corresponding development node. The third unit is used to receive code merging requests and review them according to preset code review rules; The fourth unit is used to deploy the reviewed code to test environments of different versions of the underlying framework, run regression testing algorithms to generate test cases based on the code changes and execute them, record performance data and calculate compatibility scores using support vector machine algorithms, and generate version compatibility test reports based on compatibility scores and performance data. The fifth unit is used to determine the release version of the algorithm plugin based on the version compatibility report, deploy the release version to the plugin library in the collaborative development environment, and synchronize the release information to each development node.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images