Algorithm plug-in collaborative development method and system based on multi-version control

Abstract

The invention provides an algorithm plug-in collaborative development method and system based on multi-version control, and relates to the technical field of software development, and the method comprises the following steps: creating a development task and distributing the development task to a plurality of development nodes, constructing a dependency graph and analyzing version conflicts, performing code review, and deploying and testing in test environments of different version underlying frameworks. The compatibility score is calculated through the support vector machine, the release version is determined, and the release information is synchronized, so that collaborative development of multiple development nodes is realized, dependency conflicts are recognized in advance, and the compatibility of the algorithm plug-in under a multi-version framework is ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a collaborative development method and system for algorithm plug-ins based on multi-version control. Background Art

[0002] With the rapid development of artificial intelligence and big data technologies, algorithm plug-ins have become an indispensable component of software systems. In large-scale software projects, the collaborative development of algorithm plug-ins involves multiple development teams and development nodes, requiring effective management of code versions, dependencies, and interface compatibility. Version control is an important practice in software engineering. It allows developers to develop different features in parallel and merge code when appropriate. This is particularly important in the collaborative development of algorithm plugins, as they often need to adapt to different versions of the underlying framework while maintaining forward and backward compatibility. Traditional collaborative development methods for algorithm plug-ins still suffer from the problem that developers cannot obtain real-time information about dependency package version conflicts during the development process, resulting in frequent compatibility issues during the integration phase, increasing repair costs and the risk of project delays. Test cases are usually manually designed, making it difficult to cover all possible call scenarios and boundary conditions, and unable to accurately evaluate the compatibility performance of algorithm plug-ins on different versions of the underlying framework. In addition, development teams often make decisions about releases based on experience without objective data support, which may lead to compatibility issues after the release, affecting user experience and increasing maintenance costs. Therefore, a solution is urgently needed to solve the problems existing in the prior art. Summary of the Invention

[0003] The embodiments of the present invention provide a method and system for collaborative development of algorithm plug-ins based on multi-version control, which can at least solve some of the problems existing in the prior art.

[0004] A first aspect of an embodiment of the present invention provides a method for collaborative development of an algorithm plug-in based on multi-version control, comprising: Receive and parse algorithm plug-in development requests, create algorithm plug-in development tasks 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; Based on the dependency package information and call interface information, a dependency graph is constructed to display the call links 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 link and pushed to the corresponding development node. Receive code merge requests and review them according to pre-set code review rules; Deploy the reviewed code to the test environments of different versions of the underlying framework. Run regression testing algorithms based on the code changes to generate and execute test cases. Record performance data and calculate compatibility scores using support vector machine algorithms. Generate version compatibility test reports based on the compatibility scores and performance data. Determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node.

[0005] In an optional embodiment, Receive and parse algorithm plug-in development requests, create algorithm plug-in development tasks based on the development requests and assign them to multiple development nodes, monitor code submission operations on development nodes, and obtain dependency package information and call interface information, including: receiving a development request for an algorithm plug-in, the development request including function description information and version information, and parsing development requirements of the algorithm plug-in according to the function description information; Creating a development task based on the development requirements, assigning the development task to multiple development nodes, each of which corresponds to a code repository, and creating a corresponding development branch in the code repository; Code submission operations are monitored in the code repositories of the multiple development nodes. When code submission is detected, dependency package information and call interface information in the submitted code are parsed to generate association relationship data between the dependency package information and the call interface information.

[0006] In an optional embodiment, Based on the dependency package information and call interface information, a dependency graph is constructed to display the call links and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If there is a version conflict, conflict warning information is generated based on the dependency package version number and the corresponding call link and pushed to the corresponding development node. This includes: A dependency graph is constructed based on the dependency package information and the call interface information. The nodes of the dependency graph include dependency package nodes and interface nodes. The edges of the dependency graph represent call links between the nodes. The weight value of the dependency graph is calculated by weighting the normalized function of the number of calls and the call depth. Parsing the version number of the dependent package into a triple of a major version number, a minor version number, and a revision number, calculating comparison values between the version numbers, calculating compatibility information between versions based on the comparison values, and generating a version compatibility matrix; Perform version conflict detection on the dependency package nodes in the dependency graph using the version compatibility matrix, and determine the conflicting dependency package nodes by querying the compatibility values of the corresponding version combinations in the matrix; In the dependency graph, taking the conflicting dependency package node as the starting point, the conflict propagation distance of the adjacent nodes is iteratively calculated, and 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 link is recorded. The call link is composed of a sequence of passed nodes. The conflict impact score of the call link is calculated based on the weight value of the dependency graph. According to the conflict impact score, the push priority of the conflict warning information is calculated in combination with the developer conflict weight based on the number of code submissions and the amount of code changes. Conflict warning information including the dependency package version number, call link and repair suggestion is generated, and the conflict warning information is pushed to the corresponding development node according to the push priority.

[0007] In an optional embodiment, Parsing the version number of the dependent package into a triple of a major version number, a minor version number, and a revision number, calculating comparison values between the version numbers, and calculating compatibility information between versions based on the comparison values to generate a version compatibility matrix includes: Parse the version number of the dependent package into a triple of major version number, minor version number, and revision number, and build a version evolution directed graph based on the triple; Mark version nodes in the version evolution directed graph, construct version evolution edges based on the evolutionary relationship of version numbers, identify version branch points and version merge points along the direction of the version evolution edges, and calculate the version path feature weights between version nodes based on the connection relationship of the version evolution edges to generate a version path feature weight set; Select the first and second version numbers to be compared from the triplet, calculate the major version number difference, minor version number difference, and revision version number difference respectively, multiply the differences by the preset weighting coefficients and sum them up, obtain the corresponding weights from the version path feature weight set, multiply them to generate a comparison value, calculate the topological path feature value along the version evolution edge, and multiply it with the comparison value to generate an optimized comparison value; Set a standard compatibility threshold, multiply it with the pre-set branch adjustment coefficient and merge point evaluation coefficient to generate a compatibility threshold, determine the version type according to the version evolution edge and compare it with the corresponding compatibility threshold, output the version compatibility information, create a blank matrix, multiply the version compatibility information with the topological path eigenvalue to generate matrix element values and fill them into the blank matrix, perform symmetry constraints and transitivity optimization, and generate a version compatibility matrix.

[0008] In an optional embodiment, Deploy the reviewed code to the test environment of different versions of the underlying framework. Run the regression test algorithm based on the code changes to generate test cases and execute them. Record performance data and calculate the compatibility score using the support vector machine algorithm. Generate a version compatibility test report based on the compatibility score and performance data, including: Deploy the reviewed code to test environments with different versions of the underlying framework, configure system resources in the test environment, record environment operating parameters in real time through the environment monitoring and collection mechanism, generate environment configuration information, extract the reviewed code changes and record them in the code version tracking table, execute deployment in the test environment according to the code version tracking table, and generate deployment log information; Parse code changes to extract the changed code, build a code call relationship diagram, and analyze the change propagation path. Determine the impact of the change based on the change propagation path, generate a change impact analysis report, determine the test scope based on the change impact analysis report, run the regression test algorithm, generate an initial test case set, perform deduplication optimization, and organize the optimized test cases into an execution sequence. Run test cases in the test environment according to the execution sequence, record performance data, and generate raw performance data based on the error information during the test execution. Standardize the raw performance data and calculate the compatibility score through the support vector machine algorithm. Generate a version compatibility test report based on the compatibility score and performance data.

[0009] In an optional embodiment, Parse code changes to extract changed code, build a code call relationship diagram, and analyze the change propagation path. Determine the impact of the change based on the change propagation path, and generate a change impact analysis report including: An abstract syntax tree is used to parse the code change content 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. A code entity node set is constructed based on the changed code information. A dependency edge set is constructed based on the runtime call chain information. The code entity node set and the dependency edge set are combined to construct a code call relationship graph. Calculating the static dependency edge weight and the dynamic call chain weight in the code call relationship graph, wherein the static dependency edge weight is determined by the weighted sum of the direct dependency strength and the coupling degree, and the dynamic call chain weight is determined by the execution frequency ratio, and weightedly fusing the static dependency edge weight and the dynamic call chain weight to obtain a hybrid edge weight; Based on the code call relationship graph, a breadth-first search algorithm is used to analyze the change propagation path, and the node impact propagation probability is calculated, where the impact propagation probability is determined by the product of the sum of the product of the impact propagation probability of the upstream node and the hybrid edge weight and the product of the distance decay function, and the change propagation path is screened according to a preset threshold; The impact score of the module is calculated based on the change propagation path to determine the impact scope of the change, where the impact score is determined by the sum of the product of the impact propagation probability of the nodes in the module and the pre-acquired node importance. The impact degree is graded according to the impact score to generate a change impact analysis report.

[0010] In an optional embodiment, Determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node, including: Analyzing a version compatibility report to determine a release version of the algorithm plug-in, wherein the version compatibility report includes compatibility test results of the algorithm plug-in with different versions of development environments; Deploying the algorithm plug-in to a plug-in library of a collaborative development environment based on the release version, wherein the plug-in library is used to manage different versions of the algorithm plug-in; A plug-in 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 plug-in library according to the plug-in update message.

[0011] A second aspect of an embodiment of the present invention provides an algorithm plug-in collaborative development system based on multi-version control, comprising: The first unit is used to receive and parse the development request of the algorithm plug-in, create the development task of the algorithm plug-in based on the development request and assign it to multiple development nodes, monitor the code submission operation of the development node and obtain the dependency package information and call interface information; The second unit is used to build a dependency graph based on the dependency package information and the call interface information, showing the call links between nodes and version compatibility information, analyze the dependency package versions in the dependency graph, and if there is a version conflict, generate a conflict warning message based on the dependency package version number and the corresponding call link and push it to the corresponding development node; The third unit is used to receive code merge requests and review them according to the preset code review rules; The fourth unit deploys the reviewed code into the test environment of different versions of the underlying framework, runs the regression test algorithm based on the code changes to generate test cases and executes them, records performance data and calculates the compatibility score using the support vector machine algorithm, and generates a version compatibility test report based on the compatibility score and performance data; The fifth unit is used to determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node.

[0012] According to a third aspect of an embodiment of the present invention, an electronic device is provided, including: A processor and a memory for storing processor-executable instructions, wherein the processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0013] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described above is implemented.

[0014] In the present invention, a collaborative development method for algorithm plug-ins with multi-version control is used to achieve efficient collaboration and version compatibility management between development nodes, effectively avoid dependency conflicts and version incompatibility problems, and improve the development efficiency and quality of algorithm plug-ins. A dependency graph is constructed based on dependency package information and call interface information, which can monitor and warn potential version conflicts in real time. By visually presenting call links and version compatibility information, developers can identify and solve problems in a timely manner, reducing the complexity and cost of subsequent integration testing. A support vector machine algorithm is used to calculate compatibility scores and generate version compatibility test reports, which provides a quantitative basis for algorithm plug-in release decisions, ensures the stability and compatibility of released versions in different underlying framework environments, and improves test coverage and accuracy through automated test case generation and execution mechanisms. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A flowchart of a method for collaborative development of algorithm plug-ins based on multi-version control according to an embodiment of the present invention is provided; Figure 2 This is a working simulation diagram of a dependency package conflict detection and early warning system for an algorithm plug-in collaborative development method based on multi-version control according to an embodiment of the present invention; Figure 3 This is a simulation effect diagram of the code change impact propagation of the algorithm plug-in collaborative development method based on multi-version control in an embodiment of the present invention. DETAILED DESCRIPTION

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0017] The following specific embodiments are used to describe the technical solution of the present invention in detail. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0018] Figure 1 FIG. 1 is a flow chart of a collaborative development method for an algorithm plug-in based on multi-version control according to an embodiment of the present invention. Figure 1 As shown, the method includes: Receive and parse algorithm plug-in development requests, create algorithm plug-in development tasks 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; Based on the dependency package information and call interface information, a dependency graph is constructed to display the call links 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 link and pushed to the corresponding development node. Receive code merge requests and review them according to pre-set code review rules; Deploy the reviewed code to the test environments of different versions of the underlying framework. Run regression testing algorithms based on the code changes to generate and execute test cases. Record performance data and calculate compatibility scores using support vector machine algorithms. Generate version compatibility test reports based on the compatibility scores and performance data. Determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node.

[0019] In an optional embodiment, Receive and parse algorithm plug-in development requests, create algorithm plug-in development tasks based on the development requests and assign them to multiple development nodes, monitor code submission operations on development nodes, and obtain dependency package information and call interface information, including: receiving a development request for an algorithm plug-in, the development request including function description information and version information, and parsing development requirements of the algorithm plug-in according to the function description information; Creating a development task based on the development requirements, assigning the development task to multiple development nodes, each of which corresponds to a code repository, and creating a corresponding development branch in the code repository; Code submission operations are monitored in the code repositories of the multiple development nodes. When code submission is detected, dependency package information and call interface information in the submitted code are parsed to generate association relationship data between the dependency package information and the call interface information.

[0020] When receiving a request to develop an algorithm plug-in, the system parses the functional description, extracts keywords, and matches them against a pre-defined functional classification library to determine the development requirements for the algorithm plug-in. For example, when receiving a request to "develop an image processing plug-in supporting 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 plug-in falls into the computer vision category and needs to implement functions such as face detection, feature extraction, and recognition and matching.

[0021] After analysis is complete, development tasks are created based on development requirements and broken down into multiple subtasks. Subtasks are divided based on functional modules, such as decomposing a face recognition plug-in into a face detection module, a feature extraction module, and a recognition and matching module. A task assignment algorithm selects the appropriate development node for each subtask based on the development node's expertise and historical performance data. 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.

[0022] After task assignment is complete, a development branch is created in the code repository corresponding to each development node. Development branches are named using the format "plugin-function-version-node identifier," such as "plugin-facerecog-v1.0-nodeA." Access permissions and merge rules are also set for each development branch to ensure security and code quality during the development process. When creating a branch, a basic code template is generated, including a standard file structure, interface definitions, and a documentation framework, to help developers quickly start coding.

[0023] The code repository of each development node is monitored in real time, and code submission events are captured through the version control system's hook mechanism. When a code submission is detected, the submitted code is automatically pulled and statically analyzed. Code analysis focuses on two aspects: dependency package information and call interface information. For dependency package information, the project's configuration files (such as package.json, requirements.txt, pom.xml, etc.) are parsed to extract the name, version, and source of the dependent package. For example, when parsing the requirements.txt file of a Python project, dependency information such as "numpy==1.19.5" and "opencv-python==4.5.1.48" are extracted.

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

[0025] The parsed dependency package information and call interface information are stored in a relational database, and an association is established between the two. Association data is stored using a graph structure, with nodes representing dependency packages or interfaces and edges representing 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 say, "Node A's face detection module calls the OpenCV library's cv2.CascadeClassifier interface for face detection at a frequency of 10 times per second, with the parameter being the path to the pre-trained model file."

[0026] Perform security and compatibility checks on dependent packages, identifying known vulnerabilities, outdated versions, and incompatible components. When potential issues are discovered, a warning message is generated and the relevant development nodes are notified. For example, if a high-risk security vulnerability is detected in a dependent package, a notification will be sent stating that the dependent package numpy 1.19.5 has the CVE-2021-xxxxx security vulnerability and recommends upgrading to version 1.20.0 or later.

[0027] To optimize collaborative development efficiency, we analyze development progress based on the frequency and content of code submissions and compare it against the initial plan. When we detect that a development node is behind schedule or has significant code quality issues, we adjust resource allocation or provide additional support. We also regularly generate development reports, including information such as module completion, code quality metrics, and dependency maps, to help project managers understand development status.

[0028] After all development nodes complete their respective tasks, they coordinate the code merge process, checking code compatibility and resolving conflicts. After the merge is complete, a complete dependency report and interface documentation are generated to support the testing, deployment, and maintenance of the algorithm plug-in. For example, a technical document is generated containing information such as "The face recognition plug-in relies on OpenCV 4.5.1 for image processing, 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 plug-ins, reduces maintenance costs, and provides reliable support for technological innovation for enterprises.

[0029] In this embodiment, by receiving development requests and parsing development requirements, the automatic allocation of algorithm plug-in development tasks is achieved, avoiding the errors and inefficiencies that may be caused by manual task allocation. By real-time monitoring of code submission operations 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.

[0030] In an optional embodiment, Based on the dependency package information and call interface information, a dependency graph is constructed to display the call links and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If there is a version conflict, conflict warning information is generated based on the dependency package version number and the corresponding call link and pushed to the corresponding development node. This includes: A dependency graph is constructed based on the dependency package information and the call interface information. The nodes of the dependency graph include dependency package nodes and interface nodes. The edges of the dependency graph represent call links between the nodes. The weight value of the dependency graph is calculated by weighting the normalized function of the number of calls and the call depth. Parsing the version number of the dependent package into a triple of a major version number, a minor version number, and a revision number, calculating comparison values between the version numbers, calculating compatibility information between versions based on the comparison values, and generating a version compatibility matrix; Perform version conflict detection on the dependency package nodes in the dependency graph using the version compatibility matrix, and determine the conflicting dependency package nodes by querying the compatibility values of the corresponding version combinations in the matrix; In the dependency graph, taking the conflicting dependency package node as the starting point, the conflict propagation distance of the adjacent nodes is iteratively calculated, and 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 link is recorded. The call link is composed of a sequence of passed nodes. The conflict impact score of the call link is calculated based on the weight value of the dependency graph. According to the conflict impact score, the push priority of the conflict warning information is calculated in combination with the developer conflict weight based on the number of code submissions and the amount of code changes. Conflict warning information including the dependency package version number, call link and repair suggestion is generated, and the conflict warning information is pushed to the corresponding development node according to the push priority.

[0031] Obtain project dependency package information and call interface information by parsing the project's configuration files, code files, and call logs. Dependency package information includes package name, version number, and dependency relationships. Call interface information includes interface name, package, and call count. For example, in a microservice project, service A depends on version 1.2.3 of package P, and service B depends on version 1.3.0 of package P. These two services call each other through gateway G.

[0032] Based on the acquired information, a dependency graph is constructed. The dependency graph uses dependent package nodes and interface nodes as vertices, and call relationships as edges. Each dependent package node contains the package name and version number attributes, for example, "P-1.2.3" represents version 1.2.3 of package P. Each interface node contains the interface name and package to which it belongs, for example, "getUser-P" represents the getUser interface in package P. Call links, which serve as graph edges, connect these nodes, such as the call link from service A to interface getUser-P and then to package P-1.2.3. Edge weights in the graph are calculated based on the number of calls and call depth. The number of calls reflects the frequency of use of the call link, while the call depth reflects the position of the call within the entire system. When calculating the weight, the number of calls and call depth are normalized separately and then weighted summed. For example, if a call link has 100 calls (normalized value is 0.8), a call depth of 2 (normalized value is 0.6), and the weights of the two are 0.6 and 0.4 respectively, then the weight of the edge is 0.8×0.6+0.6×0.4=0.72.

[0033] Parse the version numbers of dependent packages, such as "1.2.3," into a triple consisting of major version 1, minor version 2, and revision number 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 by calculating the difference between the components: the major version difference is 0, the minor version difference is 1, and the revision difference is -3. Based on the comparison values, a version compatibility matrix is generated, with each element representing the compatibility between the two versions. According to the Semantic Versioning specification, two versions with different major version numbers are generally incompatible. Increasing minor versions while maintaining the same major version number are backwards compatible, and changes in revision numbers 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).

[0034] Use the version compatibility matrix to perform version conflict detection on the dependent package nodes in the dependency graph. Look for different version nodes of the same package in the graph and determine whether there is a conflict by querying the compatibility value of the corresponding version combination in the matrix. When the compatibility value is lower than the preset threshold (such as 0.5), it is determined to be a version conflict. In this example, it was found that package P existed in two versions, 1.2.3 and 1.3.0, with a compatibility value of 0.8, which is higher than the threshold and is not considered a conflict for the time being. For further verification, the interface calls of the two versions were checked and it was found that the implementation of the same-named interface in the two versions was different, which was marked as a potential conflict point.

[0035] For detected conflicting dependency package nodes, conflict propagation analysis is performed within the dependency graph. Starting from the conflicting dependency package node, a method similar to the Dijkstra algorithm is used to calculate the conflict propagation distances between adjacent nodes. Distance calculations take into account the weight of the call link. Edges with larger weights have less impact on conflict propagation and shorter propagation distances. For example, if the edge weight from node A to the conflicting node P-1.2.3 is 0.72, the initial propagation distance is 1 / 0.72 ≈ 1.39. The propagation distances between adjacent nodes are iteratively calculated. When a shorter propagation path is discovered, the node's propagation distance is updated and the corresponding call link is recorded. The calculated propagation distances for service A are 1.39, and for service B, 1.56.

[0036] Based on the propagation distance and call chain, a conflict impact score is calculated for each affected node. The impact score takes into account the propagation distance, call chain weight, and the importance of the nodes on the chain. For example, service A has an impact score of 85 (high), and service B has an impact score of 70 (medium). Developer conflict weights are also calculated based on the number of code commits and the amount of code changes. Developers with more commits and larger amounts of changes receive higher weights. For example, developer X has 50 commits to service A and 5,000 lines of changes, resulting in a calculated weight of 0.8. Developer Y has 30 commits to service B and 3,000 lines of changes, resulting in a weight of 0.6.

[0037] The conflict impact score and developer conflict weight are combined to generate a push priority for conflict warning information. The higher the priority value, the higher the priority required. 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 is generated, including the dependency package version number, call link, and repair suggestions. For example, "There is a version conflict in dependency package P (1.2.3 vs. 1.3.0), and the call link affecting service A is A→getUser→P. It is recommended to upgrade to the unified 1.3.0 version to ensure compatibility." Conflict warning information is pushed to the corresponding development node according to the push priority to ensure that important conflicts are handled first.

[0038] In this embodiment, by constructing a dependency graph and introducing a weight calculation mechanism based on the number of calls and call depth, an accurate quantitative representation of the dependency relationship is achieved. It not only intuitively shows the calling relationship between the dependent packages and interfaces, but also reflects the dependency strength through the weight value, providing a reliable data basis for subsequent conflict analysis. The version number triple decomposition and version compatibility matrix are used for version conflict detection. Compared with the traditional version comparison method, it can more accurately identify compatibility issues between versions. By converting the version relationship into a computable numerical relationship, the accuracy and efficiency of version conflict detection are significantly improved. By calculating the conflict propagation distance and the conflict impact score, an accurate assessment of the impact range of the version conflict is achieved, and the efficiency of handling version conflicts is improved.

[0039] Figure 2 This is a working simulation diagram of the dependency package conflict detection and early warning system of the algorithm plug-in collaborative development method based on multi-version control in an embodiment of the present invention, showing the workflow and core technical elements of the dependency package conflict detection and early warning system.

[0040] Figure 2 In this simulation, a microservice system consists of two service nodes (Service A and Service B), each dependent 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), and dependent package nodes, as well as the call relationships between them. Each call link is annotated with a weight. 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 as a normalized function of the number of calls and the call depth. The version compatibility matrix at the top of the figure shows the compatibility scores between different versions. For example, the compatibility score of P-1.2.3 with P-1.3.0 is 0.8 (indicating good compatibility), while the compatibility score with version 2.0.0 is only 0.2 (indicating poor compatibility). The system uses this matrix to detect conflicts, marking the conflict points between two versions with an "X" in the center of the figure. For each detected conflict, the system calculated the conflict propagation distance, which was 1.39 for Service A and 1.56 for Service B. Based on this, the system calculated an impact score of 85 for Service A and 70 for Service B. Integrating developer information, such as Developer X's 50 commits to Service A and 5,000 lines of code changes, yields a weight of 0.8; Developer Y's corresponding data is 30 commits, 3,000 lines of code, 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 key information such as a description of the version conflict and the affected call chain, accurately reflecting the conflict detection and warning mechanism of this technical solution.

[0041] In an optional embodiment, Parsing the version number of the dependent package into a triple of a major version number, a minor version number, and a revision number, calculating comparison values between the version numbers, and calculating compatibility information between versions based on the comparison values to generate a version compatibility matrix includes: Parse the version number of the dependent package into a triple of major version number, minor version number, and revision number, and build a version evolution directed graph based on the triple; Mark version nodes in the version evolution directed graph, construct version evolution edges based on the evolutionary relationship of version numbers, identify version branch points and version merge points along the direction of the version evolution edges, and calculate the version path feature weights between version nodes based on the connection relationship of the version evolution edges to generate a version path feature weight set; Select the first and second version numbers to be compared from the triplet, calculate the major version number difference, minor version number difference, and revision version number difference respectively, multiply the differences by the preset weighting coefficients and sum them up, obtain the corresponding weights from the version path feature weight set, multiply them to generate a comparison value, calculate the topological path feature value along the version evolution edge, and multiply it with the comparison value to generate an optimized comparison value; Set a standard compatibility threshold, multiply it with the pre-set branch adjustment coefficient and merge point evaluation coefficient to generate a compatibility threshold, determine the version type according to the version evolution edge and compare it with the corresponding compatibility threshold, output the version compatibility information, create a blank matrix, multiply the version compatibility information with the topological path eigenvalue to generate matrix element values and fill them into the blank matrix, perform symmetry constraints and transitivity optimization, and generate a version compatibility matrix.

[0042] Parse the version number of the dependent package. For example, the dependent package version number "1.2.3" can be parsed into a triple (1, 2, 3) consisting of major version number 1, minor version number 2, and revision number 3. Multiple version numbers, such as "1.0.0", "1.1.0", "1.1.1", "2.0.0", etc., are parsed into corresponding triples as the basis for constructing a directed graph of version evolution.

[0043] Based on the parsed triples, a directed version evolution graph is constructed. In this graph, each version number is a node, and the evolutionary relationships between versions are directed edges. For example, the evolution from version "1.0.0" to "1.1.0" and then to "1.1.1", and the branching of "1.0.0" to "2.0.0" form a directed version evolution 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.

[0044] For each edge in the directed version evolution graph, a version path feature weight is calculated. This weight calculation takes into account 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 the base weight is 0.9. 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. Weights are calculated for all version paths, forming the set of version path feature weights {0.82, 0.75, 0.95...}.

[0045] When the compatibility of two version numbers needs to be compared, the first and second version numbers to be compared are selected, such as "1.1.0" and "1.2.0". The major version number difference (0), the minor version number difference (1), and the revision version number difference (0) are calculated. Assuming that the preset weighting coefficients are 10, 2, and 0.5, respectively, the sum of the product of the difference and the coefficient is calculated, that is, 0×10+1×2+0×0.5=2. From the previously generated version path feature weight set, the path weight from "1.1.0" to "1.2.0" is obtained. Assuming it is 0.88, multiply 2 by 0.88 to obtain a preliminary comparison value of 1.76.

[0046] Calculate the topological path eigenvalue between two versions. If they are on the same direct path in the version evolution graph, the eigenvalue is 1.0. If they pass through a branch point, the eigenvalue may drop to 0.9. If they pass through multiple branch points or merge points, the eigenvalue further drops to 0.85. Multiply the initial comparison value of 1.76 by the topological path eigenvalue of 0.85 to obtain the optimized comparison value of 1.496.

[0047] 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 considered compatible.

[0048] 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 version pair, calculate their compatibility information and multiply the result by the topology path eigenvalue to create the matrix element value. If "1.1.0" and "1.1.1" are compatible with an eigenvalue of 0.95, then the corresponding matrix element is set to 0.95; if they are incompatible, the value is set to -0.95; if the versions are the same, the value is set to 1.0.

[0049] To ensure the validity of the matrix, symmetry constraints are enforced. 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 represents compatibility between versions "1.0.0" and "1.1.0", then A[2][1] should also be 0.95.

[0050] Perform transitive optimization. If versions A and B are compatible, and B and C are compatible, but the compatibility between A and C is unknown or uncertain, infer that A and C are likely compatible, and adjust the value of A[a][c] in the matrix appropriately. For example, if A["1.0.0"]["1.1.0"] = 0.95 and A["1.1.0"]["1.1.1"] = 0.92, but the value of A["1.0.0"]["1.1.1"] is low or negative, it can be adjusted to 0.95 × 0.92 = 0.874, indicating a higher possibility of compatibility.

[0051] In this embodiment, by parsing the version number into triples and constructing a version evolution directed graph, the version evolution relationship is innovatively converted into a computable graph structure model, which can not only clearly display the evolution path between versions, but also effectively capture the complex topological relationship in version management by identifying branch points and merge points. A multi-dimensional version compatibility evaluation mechanism is introduced, and the precise quantification of version compatibility is achieved through the combined calculation of version number difference calculation, path feature weight and topological path feature value, which significantly improves the accuracy of compatibility evaluation. Based on the matrix-based compatibility representation method, combined with symmetry constraints and transitive optimization, a mathematically rigorous version compatibility evaluation system is constructed, which not only ensures the consistency and reliability of the compatibility evaluation results, but also provides efficient data structure support for subsequent version conflict detection and processing.

[0052] In an optional embodiment, Deploy the reviewed code to the test environment of different versions of the underlying framework. Run the regression test algorithm based on the code changes to generate test cases and execute them. Record performance data and calculate the compatibility score using the support vector machine algorithm. Generate a version compatibility test report based on the compatibility score and performance data, including: Deploy the reviewed code to test environments with different versions of the underlying framework, configure system resources in the test environment, record environment operating parameters in real time through the environment monitoring and collection mechanism, generate environment configuration information, extract the reviewed code changes and record them in the code version tracking table, execute deployment in the test environment according to the code version tracking table, and generate deployment log information; Parse code changes to extract the changed code, build a code call relationship diagram, and analyze the change propagation path. Determine the impact of the change based on the change propagation path, generate a change impact analysis report, determine the test scope based on the change impact analysis report, run the regression test algorithm, generate an initial test case set, perform deduplication optimization, and organize the optimized test cases into an execution sequence. Run test cases in the test environment according to the execution sequence, record performance data, and generate raw performance data based on the error information during the test execution. Standardize the raw performance data and calculate the compatibility score through the support vector machine algorithm. Generate a version compatibility test report based on the compatibility score and performance data.

[0053] 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 environment is configured with identical hardware resources, including an 8-core CPU, 16GB of memory, and 500GB of storage. An environmental monitoring and collection mechanism records real-time operating parameters such as CPU utilization, memory usage, and disk I / O, generating an environment configuration file. 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 a code version tracking table, including information such as the changed file path, changed line number, code snippet before and after the change, and the change author. For example, in the user authentication module, the tracking table records that lines 125-140 of the authentication.java file were modified from basic authentication to token authentication. Deployment instructions are executed in each test environment based on the code version tracking table, generating deployment logs containing deployment time, status, and resource usage.

[0054] After deployment, the code changes were parsed and the modified code extracted. Taking the authentication module change as an example, the code segments related to token authentication were extracted, including the token generation function, validation function, and expiration handling function. A code call graph was constructed, with nodes representing functions or classes and edges representing call relationships. A depth-first search algorithm was used to analyze the change propagation path. In the actual case, the authentication module change affected related functions such as user login, permission verification, and security logging. Based on the change propagation path, the scope of the change was determined, and a change impact analysis report was generated. This report included three directly affected modules, five indirectly affected modules, and two potential risk points. Based on the change impact analysis report, the test scope was determined to include the authentication module, user module, and permission module. A regression testing algorithm was then run to generate an initial test case set. This initial test case set contained 108 test cases, covering scenarios such as normal login and abnormal login processes, token expiration handling, and permission verification. Deduplication optimization was performed on the initial test case set, removing 25 test cases with duplicate functionality and retaining 83 test cases. These were then organized into execution sequences based on inter-test case dependencies. For example, token generation testing needs to be executed before token verification testing, and permission verification testing needs to be executed after user login testing.

[0055] Test cases were run in each test environment according to the execution sequence, and performance data such as response time, CPU utilization, memory usage, and success rate were recorded. In the Version A environment, the authentication module had an average response time of 45ms, a peak CPU utilization of 35%, a memory increment of 120MB, and a test case success rate of 98%. In the Version B environment, the authentication module had an average response time of 48ms, a peak CPU utilization of 38%, a memory increment of 125MB, and a test case success rate of 97%. In the Version C environment, the authentication module had an average response time of 62ms, a peak CPU utilization of 42%, a memory increment of 140MB, and a test case success rate of 92%. Error information collected during test execution was counted, and seven anomalies were discovered in the Version C environment, including two token verification timeout errors, three permission check failure errors, and two memory allocation errors. Raw performance data was generated, including raw execution time, resource usage, and error type.

[0056] Raw performance data was normalized, converting metrics like response time, CPU usage, and memory usage into standard scores between 0 and 1. A support vector machine algorithm was used to calculate compatibility scores, using performance data as feature vectors and radial basis kernel functions for feature mapping. The trained model then outputs compatibility scores for each version environment. The results show 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 includes a summary of test results for each version environment, performance comparison data, anomaly analysis, and recommended actions. Regarding the token verification timeout issue discovered in version C, the report recommends optimizing the token verification algorithm by increasing the timeout threshold from the current 2 seconds to 3 seconds. For permission check failures, a compatibility layer was added to handle version C-specific permission verification mechanisms. For memory allocation errors, the report recommends checking whether the memory management methods in version C conflict with the memory requests of the new code. The test report also includes a version compatibility trend chart, showing that the current code changes have significantly decreased compatibility with version C, requiring special attention.

[0057] In this embodiment, by deploying code in a test environment of a multi-version underlying framework and monitoring the environment 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 diagram and analyzing the change propagation path, the test scope is accurately positioned, redundant testing is effectively avoided, and the test efficiency is significantly improved. Through standardized processing and the calculation of compatibility scores, a quantitative evaluation of version compatibility is achieved, which can effectively identify potential performance issues and compatibility risks.

[0058] In an optional embodiment, Parse code changes to extract changed code, build a code call relationship diagram, and analyze the change propagation path. Determine the impact of the change based on the change propagation path, and generate a change impact analysis report including: An abstract syntax tree is used to parse the code change content 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. A code entity node set is constructed based on the changed code information. A dependency edge set is constructed based on the runtime call chain information. The code entity node set and the dependency edge set are combined to construct a code call relationship graph. Calculating the static dependency edge weight and the dynamic call chain weight in the code call relationship graph, wherein the static dependency edge weight is determined by the weighted sum of the direct dependency strength and the coupling degree, and the dynamic call chain weight is determined by the execution frequency ratio, and weightedly fusing the static dependency edge weight and the dynamic call chain weight to obtain a hybrid edge weight; Based on the code call relationship graph, a breadth-first search algorithm is used to analyze the change propagation path, and the node impact propagation probability is calculated, where the impact propagation probability is determined by the product of the sum of the product of the impact propagation probability of the upstream node and the hybrid edge weight and the product of the distance decay function, and the change propagation path is screened according to a preset threshold; The impact score of the module is calculated based on the change propagation path to determine the impact scope of the change, where the impact score is determined by the sum of the product of the impact propagation probability of the nodes in the module and the pre-acquired node importance. The impact degree is graded according to the impact score to generate a change impact analysis report.

[0059] Receive code changes submitted by developers, including new, modified, and deleted code files. Use an abstract syntax tree (AST) parser to parse each changed file. For example, for Java, use the JavaParser library to build the AST; for Python, use the ast module to parse the code. By comparing the ASTs before and after the change, extract the specific changed code entities, including classes, methods, attributes, etc. In the specific implementation, record the full identifier, change type, line number range, and other information of each changed entity. For example, for method changes, record the method signature, parameter list, return type, and changed line number.

[0060] To capture runtime call relationships, monitoring points are injected into the code during runtime, using bytecode enhancement or proxy technology 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 upon method entry and exit. The monitoring points collect information including the calling method identifier, the called method identifier, the call timestamp, the call duration, and the 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 to reflect the call relationships and frequency of the code during actual operation.

[0061] A code call relationship graph is constructed based on the extracted changed code information and runtime call chain information. Nodes in the graph represent code entities, including classes, methods, and properties; 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. Changed entities are labeled with the change type and a summary of the change content. 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, and other aspects of the code; dynamic dependency edges are determined by analyzing runtime call chain data. This information is combined to create a complete code call relationship graph.

[0062] For the constructed code call graph, edge weights are calculated to reflect dependency strength. Static dependency edge weights are determined by weighting direct dependency strength and coupling. Direct dependency strength indicates the number of direct calls between two entities. Coupling is calculated by analyzing the shared data structures and the complexity of the mutual calls between the two entities. For example, if method A calls method B and passes multiple parameters, its coupling is higher than if it passes only a single parameter. Dynamic call chain weights are determined by the execution frequency ratio, which is the percentage of all calls made by that call chain. For example, if a method is called 1000 times during system operation, and 800 of those calls are from a specific upstream method, the execution frequency ratio for that call chain is 0.8. The static dependency edge weights are weighted and combined with the dynamic call chain weights to create a hybrid edge weight. The weighting factors can be adjusted based on project characteristics; typically, the static weight ratio is 0.4 and the dynamic weight ratio is 0.6.

[0063] Based on the constructed code call 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 along the edges. For each traversed node, its impact propagation probability is calculated. The impact propagation probability of a node is determined by multiplying the product of the impact propagation probabilities of all its upstream nodes and the corresponding blending edge weight, and then multiplying it by a distance decay function. The distance decay function reflects the property that influence decreases with increasing propagation distance and can be used as a function that is inversely proportional to distance. The initial impact propagation probability of the changed node is set to 1.0. For example, if the impact propagation probability of node A is 0.8, the blending edge weight from A to B is 0.6, and the distance is 2, then the impact propagation probability of B being affected by A is 0.8 × 0.6 × (1 / 2) = 0.24. Change propagation paths are filtered based on a preset threshold (typically 0.1), retaining only those paths with an impact propagation probability greater than the threshold.

[0064] Based on the filtered change propagation path, the impact score of each module is calculated to determine the impact scope of the change. The module impact score is determined by the sum of the impact propagation probabilities of all nodes within the module multiplied by the node importance. Node importance is pre-assessed based on factors such as code complexity, number of historical defects, and business importance. For example, if module M contains nodes P, Q, and R, with impact propagation probabilities of 0.6, 0.4, and 0.2, respectively, and importances of 0.8, 0.5, and 0.9, respectively, the impact score of M is 0.6 × 0.8 + 0.4 × 0.5 + 0.2 × 0.9 = 0.86. The impact score is used to categorize the impact level: 0.8 and above is considered high impact, 0.5-0.8 is considered medium impact, and below 0.5 is considered 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 recommended testing scope.

[0065] In this embodiment, a code call relationship graph is constructed by combining static code analysis and dynamic runtime monitoring, thereby achieving comprehensive capture of code dependencies. The dual mechanisms of abstract syntax tree parsing and runtime call chain collection are adopted to ensure the accuracy and completeness of dependency analysis. By integrating static dependency edge weights and dynamic call chain weights, accurate quantification of code relationship strength is achieved. By considering the distance decay function and node importance, accurate calculation of the impact range of changes is achieved, which can accurately predict the impact spread range of code changes.

[0066] Figure 3 This diagram shows a simulation of the impact propagation of code changes in a collaborative development method for algorithm plug-ins based on multi-version control, simulating the path and extent of impact after 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 dependency relationships, 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.

[0067] The change begins with UserController (impact 1.0) and propagates through direct dependencies to the service layer's UserService (impact 0.92) and AuthService (impact 0.85). UserController calls UserService 72% of the time, with a mixed edge weight of 0.83; calls to AuthService 65% of the time, with a mixed edge weight of 0.78. The impact continues down to the three repositories in the persistence layer: UserRepository (impact 0.76), TokenRepository (impact 0.68), and RoleRepository (impact 0.62). UserService calls UserRepository 87% of the time, with an edge weight of 0.81; calls to TokenRepository 43% of the time, with an edge weight of 0.56. AuthService calls TokenRepository 75% of the time, with an edge weight of 0.77; and calls to RoleRepository 68% of the time, with an edge weight of 0.72. The impact ultimately propagates to the User (influence 0.53), Token (influence 0.47), and Role (influence 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 is an indirect dependency between User and Token (edge weight 0.32), and between Token and Role (edge weight 0.28).

[0068] This technical solution accurately identifies dependency paths that are difficult to detect using traditional static analysis, including CacheManager (impact 0.64), RedisClient (impact 0.52), and CacheConfig (impact 0.38). The dynamic call frequency from UserController to CacheManager is 21%, but due to its importance at runtime, the hybrid 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.

[0069] The module-level impact score calculation 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 determined: the control layer and service layer have a high impact (≥0.8), the persistence layer and cache layer have a medium impact (0.5-0.8), and the model layer has a low impact (<0.5). The change propagation path analysis based on the breadth-first search algorithm revealed four main impact paths, among which the strongest impact path was Controller→UserService→UserRepository→User, with an impact propagation probability of 0.92-0.76-0.53; the second strongest impact path was Controller→AuthService→TokenRepository→Token, with an impact propagation probability of 0.85-0.68-0.47; the third impact path was Controller→AuthService→RoleRepository→Role, with an impact propagation probability of 0.85-0.62-0.42; and the fourth impact path was Controller→CacheManager→RedisClient→CacheConfig, with an impact propagation probability of 0.64-0.52-0.38.

[0070] The formula for calculating the influence propagation probability in this technical solution is: P(n) = Σ(P(m) × W(m, n)) × D(d), where P(n) is the influence propagation probability of node n, P(m) is the influence propagation probability of upstream node m, W(m, n) is the weight of the hybrid edge from m to n, and D(d) is the distance decay function. The hybrid edge weight W(m, n) = 0.4 × S(m, n) + 0.6 × D(m, n), where S(m, n) represents the static dependency strength and coupling, and D(m, n) represents the ratio of dynamic call frequencies. Static dependency strength is determined by analyzing the number of direct calls between two entities, while coupling is calculated by analyzing the shared data structures and the complexity of the mutual calls between the two entities. For example, if method A calls method B and passes multiple parameters, its coupling is higher than when only a single simple parameter is passed. 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.

[0071] The impact propagation calculation method based on hybrid weights can effectively reduce missed reports compared to traditional methods based only on static dependencies or historical changes. The average missed report 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 hybrid dependency analysis methods.

[0072] This technical solution, combining static analysis with dynamic runtime information, not only discovers dependencies that are difficult to identify with traditional methods, but also more accurately quantifies the impact, providing a reliable basis for determining the impact of code changes and allocating testing resources. This approach allows development teams to more precisely plan test scope and prioritize high-impact modules, thereby improving the quality and efficiency of software changes.

[0073] In an optional embodiment, Determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node, including: Analyzing a version compatibility report to determine a release version of the algorithm plug-in, wherein the version compatibility report includes compatibility test results of the algorithm plug-in with different versions of development environments; Deploying the algorithm plug-in to a plug-in library of a collaborative development environment based on the release version, wherein the plug-in library is used to manage different versions of the algorithm plug-in; A plug-in 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 plug-in library according to the plug-in update message.

[0074] Receive the version compatibility report of the algorithm plug-in, which contains the compatibility test results of the algorithm plug-in and each version of the development environment. The compatibility test results include data from three dimensions: functional testing, performance testing, and stability testing. The functional test data records the functional completeness of the plug-in in each version environment, such as 98.5% in the V2.1.0 environment and 95.2% in the V2.0.0 environment; the performance test data records the execution efficiency of the plug-in in each environment, such as it takes 1.2 seconds to process 1,000 pieces of data in the V2.1.0 environment and 1.5 seconds in the V2.0.0 environment; the stability test data records the error rate of the plug-in after 24 hours of continuous operation, such as the error rate is 0.01% in the V2.1.0 environment and 0.03% in the V2.0.0 environment.

[0075] The version decision engine uses a weighted scoring mechanism based on the compatibility test results to determine the optimal release version. In the weighted scoring mechanism, functional completeness is weighted at 0.5, performance efficiency is weighted at 0.3, and stability is weighted at 0.2. For each test environment version, its comprehensive score is calculated. Taking the above data as an example, the comprehensive score of the V2.1.0 environment is: 0.5×98.5+0.3×(1000 / 1.2)+0.3×(100-0.01)=98.5, while the comprehensive score of the V2.0.0 environment is 94.8. The environment version with the highest comprehensive score is selected as the release version of the plug-in. In this example, V2.1.0 is determined to be the optimal release version.

[0076] The version adaptation processor performs the necessary adaptation processing on the algorithm plug-in based on the determined release version. The adaptation processing includes interface adjustment, dependency update, and configuration file modification. Interface adjustment ensures that the plug-in fully matches the API of the target environment version. Dependency update ensures that the third-party library used by the plug-in is compatible with the target environment, such as updating the dependent library ABC to version 3.4.2. Configuration file modification adjusts the plug-in running parameters to adapt to the target environment, such as adjusting the memory allocation parameter from 512MB to 768MB. After the adaptation is completed, the final release package of the plug-in is generated, which contains the main program file, dependent libraries, configuration files, and instruction documentation.

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

[0078] The plugin verification service performs final verification on deployed plugins, including integrity checks, security scans, and functional testing. The integrity check ensures that all necessary plugin files are intact, using the SHA-256 checksum algorithm to verify file integrity. The security scan detects potential security risks, such as unauthorized network access or system calls. Functional testing exercises the plugin's core functionality in a simulated environment to verify that it works as expected. Once verified, the plugin moves from the beta zone to the stable zone, officially enabling it to be used in production environments.

[0079] The update notification service sends plugin update messages to every development node in the collaborative development environment. Update messages are formatted in JSON and contain the plugin identifier, version number, update description, download link, and verification code. Update notifications are sent via a message queue, ensuring that even if some nodes are temporarily offline, they will still receive the update information when they reconnect.

[0080] The node update agent runs on each development node, responsible for receiving update messages and performing plugin retrieval. Upon receiving an update message, the update agent checks whether the local version is already installed. If not, it downloads the plugin package from the plugin repository. After the download is complete, the agent calculates the SHA-256 checksum of the downloaded file and compares it with the checksum in the message to ensure file integrity. Once verified, 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, enabling rollback to a previous version if necessary.

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

[0082] A second aspect of an embodiment of the present invention provides an algorithm plug-in collaborative development system based on multi-version control, comprising: The first unit is used to receive and parse the development request of the algorithm plug-in, create the development task of the algorithm plug-in based on the development request and assign it to multiple development nodes, monitor the code submission operation of the development node and obtain the dependency package information and call interface information; The second unit is used to build a dependency graph based on the dependency package information and the call interface information, showing the call links between nodes and version compatibility information, analyze the dependency package versions in the dependency graph, and if there is a version conflict, generate a conflict warning message based on the dependency package version number and the corresponding call link and push it to the corresponding development node; The third unit is used to receive code merge requests and review them according to the preset code review rules; The fourth unit deploys the reviewed code into the test environment of different versions of the underlying framework, runs the regression test algorithm based on the code changes to generate test cases and executes them, records performance data and calculates the compatibility score using the support vector machine algorithm, and generates a version compatibility test report based on the compatibility score and performance data; The fifth unit is used to determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node.

[0083] According to a third aspect of an embodiment of the present invention, an electronic device is provided, including: A processor and a memory for storing processor-executable instructions, wherein the processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0084] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described above is implemented.

[0085] The present invention may be a method, an apparatus, a system and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present invention.

[0086] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements 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. The algorithm plug-in collaborative development method based on multi-version control is characterized by: include: Receive and parse algorithm plug-in development requests, create algorithm plug-in development tasks 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; Based on the dependency package information and call interface information, a dependency graph is constructed to display the call links 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 link and pushed to the corresponding development node. Receive code merge requests and review them according to pre-set code review rules; Deploy the reviewed code to the test environments of different versions of the underlying framework. Run regression testing algorithms based on the code changes to generate and execute test cases. Record performance data and calculate compatibility scores using support vector machine algorithms. Generate version compatibility test reports based on the compatibility scores and performance data. Determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of 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 algorithm plug-in development requests, create algorithm plug-in development tasks based on the development requests and assign them to multiple development nodes, monitor code submission operations on development nodes, and obtain dependency package information and call interface information, including: receiving a development request for an algorithm plug-in, the development request including function description information and version information, and parsing development requirements of the algorithm plug-in according to the function description information; Creating a development task based on the development requirements, assigning the development task to multiple development nodes, each of which corresponds to a code repository, and creating a corresponding development branch in the code repository; Code submission operations are monitored in the code repositories of the multiple development nodes. When code submission is detected, dependency package information and call interface information in the submitted code are parsed to generate association relationship data between the dependency package information and the call interface information.

3. The method according to claim 1, characterized in that Based on the dependency package information and call interface information, a dependency graph is constructed to display the call links and version compatibility information between nodes. The dependency package versions in the dependency graph are analyzed. If there is a version conflict, conflict warning information is generated based on the dependency package version number and the corresponding call link and pushed to the corresponding development node. This includes: A dependency graph is constructed based on the dependency package information and the call interface information. The nodes of the dependency graph include dependency package nodes and interface nodes. The edges of the dependency graph represent call links between the nodes. The weight value of the dependency graph is calculated by weighting the normalized function of the number of calls and the call depth. Parsing the version number of the dependent package into a triple of a major version number, a minor version number, and a revision number, calculating comparison values between the version numbers, calculating compatibility information between versions based on the comparison values, and generating a version compatibility matrix; Perform version conflict detection on the dependency package nodes in the dependency graph using the version compatibility matrix, and determine the conflicting dependency package nodes by querying the compatibility values of the corresponding version combinations in the matrix; In the dependency graph, taking the conflicting dependency package node as the starting point, the conflict propagation distance of the adjacent nodes is iteratively calculated, and 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 link is recorded. The call link is composed of a sequence of passed nodes. The conflict impact score of the call link is calculated based on the weight value of the dependency graph. According to the conflict impact score, the push priority of the conflict warning information is calculated in combination with the developer conflict weight based on the number of code submissions and the amount of code changes. Conflict warning information including the dependency package version number, call link and repair suggestion is generated, and the conflict warning information is pushed to the corresponding development node according to the push priority.

4. The method according to claim 3, characterized in that Parsing the version number of the dependent package into a triple of a major version number, a minor version number, and a revision number, calculating comparison values between the version numbers, and calculating compatibility information between versions based on the comparison values to generate a version compatibility matrix includes: Parse the version number of the dependent package into a triple of major version number, minor version number, and revision number, and build a version evolution directed graph based on the triple; Mark version nodes in the version evolution directed graph, construct version evolution edges based on the evolutionary relationship of version numbers, identify version branch points and version merge points along the direction of the version evolution edges, and calculate the version path feature weights between version nodes based on the connection relationship of the version evolution edges to generate a version path feature weight set; Select the first and second version numbers to be compared from the triplet, calculate the major version number difference, minor version number difference, and revision version number difference respectively, multiply the differences by the preset weighting coefficients and sum them up, obtain the corresponding weights from the version path feature weight set, multiply them to generate a comparison value, calculate the topological path feature value along the version evolution edge, and multiply it with the comparison value to generate an optimized comparison value; Set a standard compatibility threshold, multiply it with the pre-set branch adjustment coefficient and merge point evaluation coefficient to generate a compatibility threshold, determine the version type according to the version evolution edge and compare it with the corresponding compatibility threshold, output the version compatibility information, create a blank matrix, multiply the version compatibility information with the topological path eigenvalue to generate matrix element values and fill them into the blank matrix, perform symmetry constraints and transitivity optimization, and generate a version compatibility matrix.

5. The method according to claim 1, wherein Deploy the reviewed code to the test environment of different versions of the underlying framework. Run the regression test algorithm based on the code changes to generate test cases and execute them. Record performance data and calculate the compatibility score using the support vector machine algorithm. Generate a version compatibility test report based on the compatibility score and performance data, including: Deploy the reviewed code to test environments with different versions of the underlying framework, configure system resources in the test environment, record environment operating parameters in real time through the environment monitoring and collection mechanism, generate environment configuration information, extract the reviewed code changes and record them in the code version tracking table, execute deployment in the test environment according to the code version tracking table, and generate deployment log information; Parse code changes to extract the changed code, build a code call relationship diagram, and analyze the change propagation path. Determine the impact of the change based on the change propagation path, generate a change impact analysis report, determine the test scope based on the change impact analysis report, run the regression test algorithm, generate an initial test case set, perform deduplication optimization, and organize the optimized test cases into an execution sequence. Run test cases in the test environment according to the execution sequence, record performance data, and generate raw performance data based on the error information during the test execution. Standardize the raw performance data and calculate the compatibility score through the support vector machine algorithm. Generate a version compatibility test report based on the compatibility score and performance data.

6. The method according to claim 5, characterized in that Parse code changes to extract changed code, build a code call relationship diagram, and analyze the change propagation path. Determine the impact of the change based on the change propagation path, and generate a change impact analysis report including: An abstract syntax tree is used to parse the code change content 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. A code entity node set is constructed based on the changed code information. A dependency edge set is constructed based on the runtime call chain information. The code entity node set and the dependency edge set are combined to construct a code call relationship graph. Calculating the static dependency edge weight and the dynamic call chain weight in the code call relationship graph, wherein the static dependency edge weight is determined by the weighted sum of the direct dependency strength and the coupling degree, and the dynamic call chain weight is determined by the execution frequency ratio, and weightedly fusing the static dependency edge weight and the dynamic call chain weight to obtain a hybrid edge weight; Based on the code call relationship graph, a breadth-first search algorithm is used to analyze the change propagation path, and the node impact propagation probability is calculated, where the impact propagation probability is determined by the product of the sum of the product of the impact propagation probability of the upstream node and the hybrid edge weight and the product of the distance decay function, and the change propagation path is screened according to a preset threshold; The impact score of the module is calculated based on the change propagation path to determine the impact scope of the change, where the impact score is determined by the sum of the product of the impact propagation probability of the nodes in the module and the pre-acquired node importance. The impact degree is graded according to the impact score to generate a change impact analysis report.

7. The method according to claim 1, characterized in that Determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node, including: Analyzing a version compatibility report to determine a release version of the algorithm plug-in, wherein the version compatibility report includes compatibility test results of the algorithm plug-in with different versions of development environments; Deploying the algorithm plug-in to a plug-in library of a collaborative development environment based on the release version, wherein the plug-in library is used to manage different versions of the algorithm plug-in; A plug-in 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 plug-in library according to the plug-in update message.

8. An algorithm plug-in collaborative development system based on multi-version control, used to implement the method according to any one of claims 1 to 7, characterized in that: include: The first unit is used to receive and parse the development request of the algorithm plug-in, create the development task of the algorithm plug-in based on the development request and assign it to multiple development nodes, monitor the code submission operation of the development node and obtain the dependency package information and call interface information; The second unit is used to build a dependency graph based on the dependency package information and the call interface information, showing the call links between nodes and version compatibility information, analyze the dependency package versions in the dependency graph, and if there is a version conflict, generate a conflict warning message based on the dependency package version number and the corresponding call link and push it to the corresponding development node; The third unit is used to receive code merge requests and review them according to the preset code review rules; The fourth unit deploys the reviewed code into the test environment of different versions of the underlying framework, runs the regression test algorithm based on the code changes to generate test cases and executes them, records performance data and calculates the compatibility score using the support vector machine algorithm, and generates a version compatibility test report based on the compatibility score and performance data; The fifth unit is used to determine the release version of the algorithm plug-in based on the version compatibility report, deploy the release version to the plug-in library of the collaborative development environment, and synchronize the release information to each development node.

9. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images