A version management method, device and equipment of an interface definition file and a medium

Abstract

The application discloses a version management method and device of an interface definition file, equipment and a medium, relates to the field of computers, and comprises the following steps: acquiring a current interface definition file set and historical interface records to perform structure difference detection and determine whether the structure composition has changed; if the structure changes, it is determined that the interface definition has changed; if no change occurs, it is determined whether the version identification information is consistent; if not, the current semantic feature mapping is extracted based on an abstract syntax tree, the current semantic feature mapping is compared with the historical semantic feature mapping, and a semantic change list is generated; according to a preset compatibility determination rule, the semantic change list is subjected to compatibility analysis, a compatibility report is output, and it is determined that the interface definition has changed; when the interface definition has changed, a preset code generation tool is called to generate target code according to the current interface definition file set and publish the target code to a target repository, and the historical interface records are updated to generate a version label for the target repository. The interface can be efficiently managed.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a method, apparatus, device, and medium for version management of interface definition files. Background Technology

[0002] With the widespread adoption of microservice architecture, RPC (Remote Procedure Call) frameworks, such as gRPC and Thrift, are commonly used for inter-service communication. These frameworks use IDL (Interface Definition Language) to define service interfaces and automatically generate client and server stub code through code generation tools.

[0003] In current development, service providers maintain interface definition files on code hosting platforms like GitLab. Service consumers need to obtain these interface definitions and generate client code to call the service. When the interface definition changes, the consumer needs to update its client code promptly; otherwise, call failures or data inconsistencies may occur. Enterprises typically have dedicated interface management platforms to coordinate this process.

[0004] In summary, how to efficiently manage interface definitions, detect changes, determine compatibility, and automatically generate client code is a problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for version management of interface definition files, which can efficiently manage interface definitions, detect changes, determine compatibility, and automatically generate client code. The specific solution is as follows: Firstly, this application provides a version management method for interface definition files, including: Obtain the current set of interface definition files and the corresponding historical interface records; wherein, the current set of interface definition files includes the main interface file and the dependent interface files, the dependent interface files are obtained by recursively identifying the dependency statements of the main interface file, and cyclic dependency detection is performed during the recursive identification process, the accessed file paths are recorded, and when an accessed file is encountered, a warning message is recorded and processing continues; the historical interface records include the file path information, version identification information and historical semantic feature mapping of the historical interface definition files; Perform structural difference detection on the current set of interface definition files and the historical interface records to determine whether the structural composition of the current set of interface definition files has changed; If the structure of the current set of interface definition files changes, it is determined that the interface definition has been changed; If the structure of the current set of interface definition files has not changed, then determine whether the version identification information corresponding to the main interface file and the dependent interface files is consistent; If there is a discrepancy in the version identification information, the corresponding current semantic feature mapping is extracted based on the abstract syntax tree of the current interface definition file set, and the current semantic feature mapping is compared with the historical semantic feature mapping to generate a corresponding semantic change list. According to the preset compatibility judgment rules, a compatibility analysis is performed on each semantic change in the semantic change list or the current interface definition file set, a corresponding compatibility report is output, and it is determined that there are changes to the interface definition. When the interface definition changes, a preset code generation tool is invoked to generate target code based on the current set of interface definition files and publish it to the target repository, update the historical interface records, and generate a corresponding version tag for the target repository.

[0006] Optionally, retrieve historical API records, including: Receive the interface synchronization request of the current set of interface definition files; the interface synchronization request includes any one or more of the following: repository address, repository branch name, and service name of the historical interface definition files; Parsing the warehouse address yields the group to which the target warehouse belongs and the name of the target warehouse; Call the preset API to obtain the historical interface definition file corresponding to the repository branch name, and obtain the version identification information of the historical interface definition file; The dependency statements of the historical main interface files in the historical interface definition file are parsed to recursively identify all dependency files and construct the corresponding dependency file list; Based on the version identification information in the historical interface definition file, a historical semantic feature mapping is constructed; By integrating the target repository's group, the target repository name, the version identifier information, the dependency file list, and the historical semantic feature mapping, historical interface records are obtained.

[0007] Optionally, the step of performing structural difference detection on the current interface definition file set and the historical interface records to determine whether the structural composition of the current interface definition file set has changed includes: Determine whether the current set of interface definition files is consistent with the main interface file path corresponding to the historical interface record, and whether the number of dependent interface files and the set of file paths of the current set of interface definition files and the historical interface record are equal; If the main interface file paths are consistent and the number of files is equal to the set of file paths, then it is determined that the structural composition has not changed. If the main interface file paths are inconsistent and / or the number of files is not equal to the set of file paths, then it is determined that the structural composition has changed.

[0008] Optionally, determining whether the version identification information corresponding to the main interface file and the dependent interface files is consistent includes: By comparing the hash values ​​of the main interface files in the current set of interface definition files and the respective main interface files in the historical interface records, the first comparison result is obtained; The dependent interface files in the current interface definition file set are sorted according to a preset file path order to obtain the first file sequence; The historical dependency records in the historical interface records are sorted according to the preset file path order to obtain the second file sequence; The version identification information of the first file sequence and the second file sequence are compared to obtain a second comparison result; If the first comparison result and / or the second comparison result indicate that the hash values ​​are inconsistent, then the version identification information is determined to be inconsistent. If the hash values ​​represented by the first comparison result and the second comparison result are consistent, then the version identification information is determined to be consistent. If the version identification information is consistent, it is determined that the current set of interface definition files has not changed, and the process ends directly.

[0009] Optionally, the step of extracting the corresponding current semantic feature map based on the abstract syntax tree of the current interface definition file set, and comparing the current semantic feature map with the historical semantic feature map to generate a corresponding semantic change list includes: The current interface definition file set is parsed to construct an abstract syntax tree, and the corresponding current semantic feature mapping is extracted based on the abstract syntax tree; wherein, the semantic feature mapping includes any one or more of service-level features, method-level features, and field-level features; The current semantic feature map is compared with the historical semantic feature map to identify semantic change items of each change type; wherein, the change type includes addition, deletion, modification and sequence change; The semantic change details of each of the semantic change items are detected to generate a corresponding semantic change list; the semantic change list includes any one or more of the change type, change level, change location, value before change, and value after change.

[0010] Optionally, the step of performing compatibility analysis on each semantic change in the semantic change list or the current interface definition file set according to preset compatibility judgment rules, and outputting a corresponding compatibility report, including: If the structure of the current interface definition file set changes, a compatibility analysis is performed on the current interface definition file set according to the preset compatibility judgment rules to identify the preset compatible changes and preset incompatible changes in the current interface definition file set. If the preset incompatible changes exist, the current interface definition file set is determined to be incompatible, and a corresponding compatibility report is output. If there is an inconsistency in the version identification information, then according to the preset compatibility judgment rules, a compatibility analysis is performed on each semantic change in the semantic change list to identify the preset compatible change items and preset incompatible change items in each semantic change. If there is a preset incompatible change item, then the current interface definition file set is determined to be incompatible, and a corresponding compatibility report is output.

[0011] Optionally, the step of calling a preset code generation tool to generate target code based on the current set of interface definition files and publishing it to the target repository, updating the historical interface records, and generating corresponding version tags for the target repository includes: Using a preset code generation tool, target code is generated based on the current interface definition file set and preset configuration parameters; The target code is submitted to the target branch of the target repository using an atomic commit method; Update the synchronization status in the historical interface record to the preset synchronization completion status, and record the submission hash value and synchronization time; When the target branch meets the preset main branch determination conditions, the version number of the target code is automatically incremented to create a corresponding version tag for the target repository.

[0012] Secondly, this application provides a version management device for interface definition files, including: The record acquisition module is used to acquire the current set of interface definition files and the corresponding historical interface records. The current set of interface definition files includes the main interface file and the dependent interface files. The dependent interface files are obtained by recursively identifying the dependency statements of the main interface file. During the recursive identification process, cyclic dependency detection is performed, and the accessed file paths are recorded. When an accessed file is encountered, a warning message is recorded and processing continues. The historical interface records include the file path information, version identification information, and historical semantic feature mapping of the historical interface definition files. The first file judgment module is used to perform structural difference detection on the current interface definition file set and the historical interface records to determine whether the structural composition of the current interface definition file set has changed; The first file determination module is used to determine that the interface definition has changed if the structure of the current interface definition file set has changed. The second file judgment module is used to determine whether the version identification information corresponding to the main interface file and the dependent interface file is consistent if the structure of the current interface definition file set has not changed. The second file determination module is used to extract the corresponding current semantic feature mapping based on the abstract syntax tree of the current interface definition file set if there is a discrepancy in the version identification information, and compare the current semantic feature mapping with the historical semantic feature mapping to generate a corresponding semantic change list. The report output module is used to perform compatibility analysis on each semantic change in the semantic change list or the current interface definition file set according to preset compatibility judgment rules, output the corresponding compatibility report, and determine that there are changes in the interface definition; The version tag generation module is used to call a preset code generation tool to generate target code based on the current set of interface definition files and publish it to the target repository when the interface definition changes, update the historical interface records, and generate corresponding version tags for the target repository.

[0013] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is used to execute the computer program to implement the version management method for the interface definition file as described above.

[0014] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the version management method for the interface definition file as described above.

[0015] In summary, this application first obtains the current set of interface definition files and the corresponding historical interface records. The current set of interface definition files includes main interface files and dependent interface files. The dependent interface files are recursively identified by parsing the dependency statements of the main interface files, and during the recursive identification process, circular dependency detection is performed, and the accessed file paths are recorded. When an accessed file is encountered, a warning message is recorded and processing continues. The historical interface records include file path information, version identification information, and historical semantic feature mapping of historical interface definition files. Structural difference detection is performed between the current set of interface definition files and the historical interface records to determine whether the structural composition of the current set of interface definition files has changed. If the structure of the current set of interface definition files has changed, it is determined that the interface definition has been changed. If the current interface... If the structure of the definition file set remains unchanged, it is determined whether the version identification information corresponding to the main interface file and the dependent interface files is consistent. If the version identification information is inconsistent, the corresponding current semantic feature mapping is extracted based on the abstract syntax tree of the current interface definition file set, and the current semantic feature mapping is compared with the historical semantic feature mapping to generate a corresponding semantic change list. According to the preset compatibility judgment rules, a compatibility analysis is performed on each semantic change in the semantic change list or the current interface definition file set, and a corresponding compatibility report is output, and it is determined that the interface definition has been changed. When the interface definition has been changed, a preset code generation tool is called to generate target code based on the current interface definition file set and publish it to the target repository, update the historical interface record, and generate a corresponding version tag for the target repository. As described above, this application obtains the current set of interface definition files and their historical records, first performing structural difference detection to determine if the structure has changed. If the structure has changed, the interface is directly determined to have changed; if the structure has not changed, version identification information is compared. When versions are inconsistent, the current semantic feature mapping is extracted and compared with historical features to generate a semantic change list. Then, compatibility analysis is performed according to compatibility judgment rules, and a report is output. Finally, after confirming the change, a code generation tool is called to generate the target code and publish it to the target repository, while updating the historical records and generating version tags. In this way, by automating and systematically managing interface definitions, manual intervention is reduced, and structural and semantic changes of interfaces are accurately detected, avoiding missed detections due to inconsistent version identifiers. At the same time, compatibility analysis can identify the impact of changes on existing systems in advance, reducing integration risks. Automatically generating and publishing client code significantly improves development efficiency, ensures consistency between interface documentation and code implementation, and enables traceable release management through version tags, facilitating rollback and collaboration. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 This application discloses a flowchart of a version management method for interface definition files. Figure 2 This is a schematic diagram of the structure of a version management device for an interface definition file disclosed in this application; Figure 3 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

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

[0019] Currently, in actual development, service providers maintain interface definition files on code hosting platforms such as GitLab. Service consumers need to obtain these interface definitions and generate client code to call the service. When the interface definition changes, the consumer needs to update the client code promptly; otherwise, call failures or data inconsistencies may occur. Enterprises typically have dedicated interface management platforms to coordinate this process. To solve the above technical problems, this application discloses a method, apparatus, device, and medium for version management of interface definition files, which can efficiently manage interface definitions, detect changes, determine compatibility, and automatically generate client code.

[0020] See Figure 1 As shown in the figure, an embodiment of the present invention discloses a version management method for interface definition files, including: Step S11: Obtain the current set of interface definition files and the corresponding historical interface records; wherein, the current set of interface definition files includes the main interface file and the dependent interface files, the dependent interface files are obtained by recursively identifying the dependency statements of the main interface file, and cyclic dependency detection is performed during the recursive identification process, the accessed file paths are recorded, and when an accessed file is encountered, a warning message is recorded and processing continues, the historical interface records include the file path information, version identification information and historical semantic feature mapping of the historical interface definition files.

[0021] In this embodiment, firstly, an interface synchronization request for the current set of interface definition files is received; the interface synchronization request includes any one or more of the following: repository address, repository branch name, and service name of historical interface definition files; the repository address is parsed to obtain the target repository group and the target repository name; a preset API is called to obtain the historical interface definition file corresponding to the repository branch name, and the version identification information of the historical interface definition file is obtained; the dependency statements of the historical main interface file in the historical interface definition file are parsed to recursively identify all dependency files and construct a corresponding dependency file list; based on the version identification information of the historical interface definition file, a historical semantic feature mapping is constructed; the target repository group, the target repository name, the version identification information, the dependency file list, and the historical semantic feature mapping are integrated to obtain the historical interface record.

[0022] Specifically, it first receives an HTTP request for the current set of interface definition files. By parsing the HTTP request, it obtains parameters such as the repository address, branch name, and service name of the current set of interface definition files. Next, it parses the repository group and repository name from the repository address, calls the API to retrieve the repository archive of the specified branch, decompresses it to a temporary directory, locates the main interface definition file, and obtains the file's commit hash value. Then, based on the dependency statements in the main interface definition file: ProtocolBuffers: import "path / to / file.proto"; Thrift: include The process involves parsing statements like `path / to / file.thrift` to obtain the referenced file paths and recursively identifying all indirectly dependent files layer by layer until the entire dependency graph is fully traversed. This process removes duplicate dependent files and constructs a complete list of dependent files. Simultaneously, using the obtained commit hash value as version identifier information, the process reads the historical semantic feature mapping stored in the historical interface records from the database. If the historical record does not exist, the process parses the historical interface definition file to construct a semantic feature mapping, forming a historical semantic feature mapping that can be used for subsequent structured comparison. This mapping is a key-value pair structure, where the key is the interface element identifier and the value is the corresponding structured feature definition. After completing the above steps, the parsed target repository group, target repository name, currently processed version identifier information, complete list of dependent files, and generated historical semantic feature mapping are structurally integrated and encapsulated into a complete historical interface record. This record will be persistently stored or temporarily stored in memory as the basic data source for subsequent interface synchronization, version rollback, or difference comparison operations, ensuring that the synchronization process of the interface definition file has complete historical backtracking and dependency awareness capabilities.

[0023] Step S12: Perform structural difference detection on the current interface definition file set and the historical interface records to determine whether the structural composition of the current interface definition file set has changed.

[0024] In this embodiment, it is determined whether the current set of interface definition files is consistent with the main interface file path corresponding to the historical interface record, and whether the number of dependent interface files in the current set of interface definition files and the historical interface record are equal to the set of file paths. If the main interface file paths are consistent and the number of files is equal to the set of file paths, it is determined that the structural composition has not changed. If the main interface file paths are inconsistent and / or the number of files is not equal to the set of file paths, it is determined that the structural composition has changed. Specifically, the main interface file path is extracted from the historical interface record and compared with the currently parsed main interface file path. If they are inconsistent, it is directly determined that the structural composition has changed, and the change type is recorded as a change in the main file path. If the paths are consistent, the number of dependent files is compared, that is, the number of all dependent interface records with non-empty parent interface identifiers in the historical interface record is counted to obtain the total number of historical dependent files, and the number of files in the current dependent file list is counted at the same time. If the numbers are not equal, it is determined that the structure has changed, and the change type is recorded as a change in the number of dependent files. If the quantities are equal, the file path sets are further compared. This involves extracting the complete file path of each record in the historical dependency interface records to construct a historical path set, and extracting all paths from the current dependency file list to construct the current path set. The set equality comparison method is called. If the two sets are completely identical, the structural composition is determined to be unchanged, and subsequent fine-grained semantic comparisons can be skipped. The historical synchronization results can be directly reused or the process can proceed to the next stage. If the sets differ, such as due to the addition, deletion, or renaming of dependency files, the structure is determined to have changed, and the record change type is determined to be a dependency path change. The above structural change detection only requires traversing the historical record and the current file list once each, with a time complexity of O(n), enabling rapid filtering of the interface definition file sets that require in-depth analysis.

[0025] Step S13: If the structure of the current set of interface definition files changes, it is determined that the interface definition has been changed.

[0026] In this embodiment, if the structure of the current set of interface definition files is determined to have changed, the interface definition is directly identified as having changed, without the need for further fine-grained semantic feature comparison.

[0027] Step S14: If the structure of the current set of interface definition files has not changed, determine whether the version identification information corresponding to the main interface file and the dependent interface file is consistent.

[0028] In this embodiment, a first comparison result is obtained by comparing the hash values ​​of the main interface files in the current interface definition file set and the historical interface records; the dependent interface files in the current interface definition file set are sorted according to a preset file path order to obtain a first file sequence; the historical dependent records in the historical interface records are sorted according to the preset file path order to obtain a second file sequence; the version identification information of the first file sequence and the second file sequence is compared to obtain a second comparison result; if the hash values ​​of the first comparison result and / or the second comparison result are inconsistent, the version identification information is determined to be inconsistent; if the hash values ​​of the first comparison result and the second comparison result are consistent, the version identification information is determined to be consistent; if the version identification information is consistent, the current interface definition file set is determined to be unchanged, and the process ends directly.

[0029] Specifically, the commit hash value of the main interface file is extracted from the current set of interface definition files. Simultaneously, the version identifier information of the main interface file stored in the historical interface records is read. These two are compared as strings to generate the first comparison result. If they are not equal, the version identifier information is directly determined to be inconsistent, indicating that the current set of interface definition files has changed relative to the historical records, and no further comparison is needed. If they are equal, the comparison of dependent interface files continues. This involves obtaining all files in the current dependent file list, sorting them in ascending lexicographical order to generate the first file sequence, and extracting the version identifier information corresponding to each dependent file in turn. Similarly, all dependent interface records with non-empty parent interface identifiers are selected from the historical interface records, sorted in ascending lexicographical order to generate the second file sequence, and the version identifier information stored in each record is extracted sequentially. Subsequently, the version identifier information at the same position in the first and second file sequences is compared bit by bit. If the hash values ​​at all positions are consistent, the second comparison result indicates consistency; otherwise, inconsistency exists. If either the first or second comparison result has a different hash value, the version identifier information is determined to be different, indicating that the current interface definition file set has undergone actual content changes. If both are consistent, the version identifier information is determined to be completely consistent, and the current interface definition file set is completely equivalent to the historical interface record in content. The synchronization process can be terminated directly without subsequent dependency resolution or compatibility analysis. This strategy of hashing first and then sorting for comparison utilizes the uniqueness and collision avoidance of submitted hash values ​​to achieve a high-confidence determination of no changes at the file content level. At the same time, sorting keeps the time complexity of multi-file comparison to O(nlogn), balancing accuracy and efficiency.

[0030] Step S15: If there is an inconsistency in the version identification information, extract the corresponding current semantic feature mapping based on the abstract syntax tree of the current interface definition file set, and compare the current semantic feature mapping with the historical semantic feature mapping to generate the corresponding semantic change list.

[0031] In this embodiment, the current interface definition file set is parsed to construct an abstract syntax tree, and the corresponding current semantic feature mapping is extracted based on the abstract syntax tree. The semantic feature mapping includes any one or more of service-level features, method-level features, and field-level features. The current semantic feature mapping is compared with the historical semantic feature mapping to identify semantic change items of various change types. The change types include addition, deletion, modification, and sequence change. The semantic change details of each semantic change item are detected to generate a corresponding semantic change list. The semantic change list includes any one or more of the change type, change level, change location, previous value, and new value.

[0032] Specifically, the interface definition parser is invoked to parse the main interface file and its dependent files into an abstract syntax tree. The parser can recognize the syntax of the interface definition language and extract service definitions, method definitions, message definitions, and field definitions. The following mapping relationships are constructed from the interface definition language: 1. Service mapping: Service name → Service definition; 2. Method mapping: Method name → Method definition (including request type and response type); 3. Message mapping: Message name → Message definition; 4. Field mapping: Message name + field name → field definition (including field type, field number, and field order).

[0033] Compare the current semantic feature map with the historical semantic feature map to identify the following change types: 1. Add: Elements that currently exist but did not exist historically (add service, add method, add message, add field); 2. Deletion: Elements that existed historically but do not currently exist (delete service, delete method, delete message, delete field); 3. Modify: Elements that exist in both the past and present but have different attributes (modify service name, modify method signature, modify field type, modify field number); 4. Order Change: The order in which fields are defined in the message changes.

[0034] For each detected change, it is encapsulated into a structure containing the change type, such as the change level of the service / method / field, the change location such as "service name.method name" or "message name.field name", the value before the change, and the value after the change. Finally, a semantic change list is generated. The time complexity of semantic content difference detection is O(m), where m is the number of semantic features.

[0035] Step S16: According to the preset compatibility judgment rules, perform compatibility analysis on each semantic change in the semantic change list or the current interface definition file set, output the corresponding compatibility report, and determine that the interface definition has been changed.

[0036] In this embodiment, in order to determine whether the interface change is compatible with the old version, an incompatible change may cause client calls using the old version interface to fail or data parsing errors.

[0037] In one specific embodiment, if the structure of the current interface definition file set changes, a compatibility analysis is performed on the current interface definition file set according to a preset compatibility determination rule to identify preset compatible changes and preset incompatible changes in the current interface definition file set. If the preset incompatible changes exist, the current interface definition file set is determined to be incompatible, and a corresponding compatibility report is output.

[0038] Specifically, the process first acquires the change types identified during the structural change detection phase and triggers a compatibility analysis process based on these. Since structural changes typically involve adjustments to file organization (e.g., renaming or moving the main interface file, adding or deleting dependency files), these structural changes are mapped to corresponding semantic change items. For example, adding a dependency file path might correspond to adding a message type or service definition, while deleting a dependency file path might correspond to deleting a message type or method. Then, all mapped semantic change items are iterated over, and preset compatibility judgment rules are applied: adding a dependency file is considered a compatible change; deleting a dependency file is considered an incompatible change because existing clients might depend on the deleted definition. If a change in the main interface file path is accompanied by a change in the service name, it is considered an incompatible change because clients can no longer locate the service using the original service name; if only the filename changes and the internal service definition remains unchanged, it is still marked as structurally incompatible and prompts for manual intervention. Finally, if any incompatible change item exists, it is considered incompatible, and an incompatible change list and risk warning are generated; if all structural changes can be mapped to compatible changes, they are considered compatible. The compatibility report also includes change statistics and specific recommendations for incompatible items, such as suggesting that methods to be deleted require a version upgrade or that compatibility bridging should be retained.

[0039] In another specific embodiment, if there is an inconsistency in the version identification information, a compatibility analysis is performed on each semantic change in the semantic change list according to a preset compatibility judgment rule to identify preset compatible change items and preset incompatible change items in each semantic change. If there is a preset incompatible change item, the current interface definition file set is determined to be incompatible, and a corresponding compatibility report is output.

[0040] Specifically, after obtaining the result of inconsistent hash values ​​of the main interface file or dependent files from the version identifier difference detection stage, the semantic change list generated in the semantic content difference detection stage is directly invoked. This list already contains the change type, change level, change location, original value, and post-change value for each change item. The compatibility analysis engine traverses this list and applies the judgment rules defined in this invention to each item: if the change type is adding a service, adding a method, adding a message type, adding a field, changing the field order, or adding an enumeration value, it is marked as a compatible change; if the change type is deleting a service, deleting a method, deleting a message type, deleting a field, deleting an enumeration value, modifying the service name, modifying the method name, modifying the request or response message type, modifying the field name, modifying the field data type, or modifying the field number, it is marked as an incompatible change. For modifying the field data type, the type conversion compatibility is further judged. After the traversal is completed, if no incompatible change items are found, the compatibility conclusion is output as compatible, and a list of compatible changes is compiled for auditing purposes; if at least one incompatible change item exists, an incompatible conclusion is output, and all incompatible change items are extracted to form an incompatible change list, which is then sorted by change level and location and appended to the report. The report also includes a summary of change statistics and a risk description for typical incompatible changes. For example, deleting a field may cause data sent by older clients to be unable to be correctly parsed by the server, and it is recommended to obsolete the field instead of deleting it directly.

[0041] Step S17: When the interface definition changes, the preset code generation tool is invoked to generate target code based on the current interface definition file set and publish it to the target repository, update the historical interface record, and generate a corresponding version tag for the target repository.

[0042] In this embodiment, when it is determined that the interface definition has changed, a preset code generation tool is used to generate target code based on the current interface definition file set and preset configuration parameters; the target code is submitted to the target branch of the target repository through an atomic commit method; the synchronization status in the historical interface record is updated to the preset synchronization completion status, and the commit hash value and synchronization time are recorded; when the target branch meets the preset main branch determination conditions, the version number of the target code is automatically incremented to create a corresponding version tag for the target repository.

[0043] Specifically, when a change in the interface definition is detected, the system first reads the preset code generation configuration parameters and target language options, calls the corresponding code generation tool, and generates the target code required by the server or client based on the current set of interface definition files. After generation, the code is pushed to the specified branch of the target repository (i.e., the artifact repository) via atomic commit, overwriting the generated code in the working directory, and performing add and commit operations. The commit message includes the branch name and version identifier of the source interface repository to ensure the integrity of the commit. Subsequently, the system updates the status field of the interface record in the database to "synchronization complete" and records the hash value and synchronization timestamp of this commit. Based on this, it determines whether the current branch meets the main branch conditions, such as the branch name being "main" or "master", or matching a predefined regular expression. If it does, the system automatically increments the version number of the artifact repository and extracts the latest tag from the existing tags in the repository that conforms to the format "v{major}.{minor}.{patch)". It should be noted that "major" is the major version number, ranging from 1 to 9; "minor" is the minor version number, ranging from 0 to 99; and "patch" is the revision number, ranging from 1 to 99. When a tag is first created, the version number is v1.0.1. Subsequent tag creations use the latest tag's version number, following a revision number priority increment rule: the revision number is incremented by 1, and if it reaches 99, it's carried over to the minor version number; if the minor version number reaches 99, it's carried over to the major version number, with a maximum major version number of 9. This generates a new tag for the artifact repository. If the main branch conditions are not met, only the commit history on the branch is retained, and no version tag is created, for independent testing on the development branch.

[0044] It should be noted that if any step fails, the synchronization status of the updated database record will be "synchronization failed," temporary resources will be cleaned up, and an error response will be returned. If a runtime exception occurs, the exception will be caught, stack trace information will be recorded, the synchronization status will be updated, temporary resources will be cleaned up, and an error response will be returned.

[0045] Understandably, the time complexity of structural difference detection is O(n), where n is the number of files; The time complexity of version identifier difference detection is O(nlogn), dominated by sorting operations; the time complexity of semantic content difference detection is O(m), where m is the number of semantic features. Therefore, the overall time complexity is O(nlogn+m). This application can skip the code generation step when the interface remains unchanged, saving time on code generation and deployment. Code generation typically involves time-consuming operations such as compilation, file I / O, and network transmission, with time overhead ranging from seconds to minutes. The time overhead of this application is in the millisecond range, significantly improving synchronization efficiency.

[0046] In addition, this application provides an interface query function, supporting service list query and detail query.

[0047] For service list queries, input pagination parameters and service names to retrieve a list of service names from the database. Query results are sorted in descending order of last synchronization time, prioritizing the most recently updated services. For each service, the system returns the following information: service name, main interface file path, last synchronization time, service repository address, artifact repository address, and import command.

[0048] For service details queries, enter the service name to retrieve all main interface records for that service from the database. Retrieve the version tag list for the artifact repository. The build returns information including the service name, latest version number, main branch commit hash, service repository address, artifact repository address, main interface file path, snapshot information for each branch, release information for each version, and compatibility status.

[0049] As described above, this embodiment of the application obtains the current set of interface definition files and their historical records, first performs structural difference detection to determine whether the structure has changed. If the structure has changed, the interface is directly determined to have changed; if the structure has not changed, the version identification information is compared. When the versions are inconsistent, the current semantic feature mapping is extracted and compared with historical features to generate a semantic change list. Then, compatibility analysis is performed according to compatibility judgment rules and a report is output. Finally, after confirming the change, the code generation tool is called to generate the target code and publish it to the target repository, while updating the historical records and generating version tags. In this way, by automating and systematically managing interface definitions, manual intervention is reduced, and structural and semantic changes of the interface are accurately detected, avoiding missed judgments due to inconsistent version identifiers. At the same time, compatibility analysis can identify the impact of changes on the existing system in advance, reducing integration risks. Automatically generating and publishing client code significantly improves development efficiency, ensures consistency between interface documentation and code implementation, and enables traceable release management through version tags, facilitating rollback and collaboration.

[0050] Based on the previous embodiment, this application discloses a version management method for interface definition files, which can efficiently manage interface definitions, detect changes, determine compatibility, and automatically generate client code. Assuming that developers need to maintain an order service for a shopping software, and the interface definition uses Protocol Buffers and is stored in the feature / add_item branch of the order_service / proto repository, the version management method for interface definition files will be described in detail.

[0051] After the developers modified the interface definition on this branch, the interface synchronization process was triggered.

[0052] First, obtain the current set of interface definition files, including the main interface file order.proto and its dependencies common.proto and item.proto, as well as historical interface records, namely the file paths, commit hashes, and semantic feature mappings recorded during the last synchronization of the main branch, which are retrieved from the database.

[0053] Next, a structural difference detection is performed, which compares the main interface file path, the number of dependency files, and the path set. If the path set is found to be completely identical, it is determined that the structure has not changed, and the process proceeds to the next step of version identifier comparison.

[0054] Next, version identification detection is performed. The commit hash values ​​of each file on the feature / add_item branch are obtained and compared one by one with the hash values ​​of the main branch in the history. A difference is found in the hash value of the main interface order.proto, indicating a version identification inconsistency, and the semantic content difference detection stage begins. The Protocol Buffers parser is used to construct an abstract syntax tree of the current interface definition file, extracting semantic features such as service name, method signature, and field number to form a current semantic feature mapping, which is then compared item by item with the historical semantic feature mapping. It is found that a CancelOrder method has been added to OrderService, and the customer_id field has been deleted from the Order message. These are recorded as two changes: a new method and a deleted field, respectively, generating a corresponding semantic change list.

[0055] Next, a compatibility analysis is performed. The semantic change list is traversed, and based on preset rules, adding the `CancelOrder` method is considered a compatible change, but deleting the `customer_id` field is considered an incompatible change. Due to the existence of incompatible changes, the final compatibility conclusion is incompatible, and a list of incompatible changes and risk warnings are output. It is recommended to smoothly evolve the process by abandoning the field rather than directly deleting it.

[0056] Finally, the code generation tool is invoked to generate target code based on the current interface definition file. This code is then atomically committed to the `feature / add_item` branch of the `order_service_gen` repository, updating the synchronization status in the database to "synchronization complete" and recording the commit hash and synchronization time. Since the current branch does not meet the requirements for a main branch, no version tag is created; only the branch commit record is retained for integration testing. Once this branch is merged into the main branch, the system will automatically trigger the main branch synchronization process, generating a version tag for the repository, updating version v1.0.2 to v1.0.3, and completing the full release of the interface version.

[0057] See Figure 2 As shown, this embodiment of the invention discloses a version management device for interface definition files, including: The record acquisition module 11 is used to acquire the current set of interface definition files and the corresponding historical interface records; wherein, the current set of interface definition files includes the main interface file and the dependent interface files, the dependent interface files are obtained by recursively identifying the dependency statements of the main interface file, and cyclic dependency detection is performed during the recursive identification process, the accessed file paths are recorded, and when an accessed file is encountered, a warning message is recorded and processing continues; the historical interface records include the file path information, version identification information and historical semantic feature mapping of the historical interface definition files; The first file judgment module 12 is used to perform structural difference detection on the current interface definition file set and the historical interface records to determine whether the structural composition of the current interface definition file set has changed. The first file determination module 13 is used to determine that the interface definition has changed if the structure of the current interface definition file set has changed. The second file judgment module 14 is used to determine whether the version identification information corresponding to the main interface file and the dependent interface file is consistent if the structure of the current interface definition file set has not changed. The second file determination module 15 is used to extract the corresponding current semantic feature mapping based on the abstract syntax tree of the current interface definition file set if there is a discrepancy in the version identification information, and compare the current semantic feature mapping with the historical semantic feature mapping to generate a corresponding semantic change list. The report output module 16 is used to perform compatibility analysis on each semantic change in the semantic change list or the current interface definition file set according to the preset compatibility judgment rules, output the corresponding compatibility report, and determine that there are changes in the interface definition. The version tag generation module 17 is used to call a preset code generation tool to generate target code based on the current set of interface definition files and publish it to the target repository when the interface definition changes, update the historical interface record, and generate a corresponding version tag for the target repository.

[0058] As described above, this application obtains the current set of interface definition files and their historical records, first performing structural difference detection to determine if the structure has changed. If the structure has changed, the interface is directly determined to have changed; if the structure has not changed, version identification information is compared. When versions are inconsistent, the current semantic feature mapping is extracted and compared with historical features to generate a semantic change list. Then, compatibility analysis is performed according to compatibility judgment rules, and a report is output. Finally, after confirming the change, a code generation tool is called to generate the target code and publish it to the target repository, while updating the historical records and generating version tags. In this way, by automating and systematically managing interface definitions, manual intervention is reduced, and structural and semantic changes of interfaces are accurately detected, avoiding missed detections due to inconsistent version identifiers. At the same time, compatibility analysis can identify the impact of changes on existing systems in advance, reducing integration risks. Automatically generating and publishing client code significantly improves development efficiency, ensures consistency between interface documentation and code implementation, and enables traceable release management through version tags, facilitating rollback and collaboration.

[0059] In some specific embodiments, the record acquisition module 11 may specifically include: The request receiving unit is used to receive the interface synchronization request of the current interface definition file set; the interface synchronization request includes any one or more of the following: the repository address of the historical interface definition file, the repository branch name, and the service name; The address resolution unit is used to resolve the warehouse address to obtain the group to which the target warehouse belongs and the name of the target warehouse. The information acquisition unit is used to call a preset API to obtain the historical interface definition file corresponding to the repository branch name, and to obtain the version identification information of the historical interface definition file; The list building unit is used to parse the dependency statements of the historical main interface files in the historical interface definition file, so as to recursively identify all dependency files and build the corresponding dependency file list. The mapping construction unit is used to construct a historical semantic feature mapping based on the version identification information of the historical interface definition file; The record acquisition unit is used to integrate the target repository's group, the target repository name, the version identification information, the dependency file list, and the historical semantic feature mapping to obtain historical interface records.

[0060] In some specific implementations, the first file determination module 12 may specifically include: The first path determination unit is used to determine whether the current interface definition file set is consistent with the main interface file path corresponding to the historical interface record, and whether the number of dependent interface files in the current interface definition file set and the historical interface record are equal to the file path set. The first path determination unit is used to determine that if the main interface file paths are consistent and the number of files is equal to the set of file paths, then the composition of the determination structure has not changed. The second path determination unit is used to determine if the main interface file paths are inconsistent and / or the number of files is not equal to the set of file paths, in order to determine if the composition of the structure changes.

[0061] In some specific implementations, the second file determination module 14 may specifically include: The first comparison result acquisition unit is used to compare the hash values ​​of the main interface files in the current set of interface definition files and the historical interface records to obtain the first comparison result. The first file sequence acquisition unit is used to sort the dependent interface files in the current interface definition file set according to the preset file path order to obtain the first file sequence; The second file sequence acquisition unit is used to sort the historical dependency records in the historical interface records according to the preset file path order to obtain the second file sequence; The second comparison result acquisition unit is used to compare the version identification information of the first file sequence and the second file sequence to obtain a second comparison result; An information judgment unit is used to determine that the version identification information is inconsistent if the hash values ​​represented by the first comparison result and / or the second comparison result are inconsistent. The first information determination unit is used to determine that the version identification information is consistent if the hash value represented by the first comparison result and the second comparison result is consistent. The second information determination unit is used to determine that the current interface definition file set has not changed if the version identification information is consistent, and then directly end the process.

[0062] In some specific implementations, the second file determination module 15 may specifically include: The mapping extraction unit is used to parse the current interface definition file set to construct an abstract syntax tree, and extract the corresponding current semantic feature mapping based on the abstract syntax tree; wherein, the semantic feature mapping includes any one or more of service-level features, method-level features, and field-level features; The change item identification unit is used to compare the current semantic feature mapping with the historical semantic feature mapping to identify semantic change items of various change types; wherein, the change types include addition, deletion, modification and sequence change; The change list generation unit is used to detect the semantic change details of each of the semantic change items in order to generate a corresponding semantic change list; the semantic change list includes any one or more of the change type, change level, change location, value before change, and value after change.

[0063] In some specific implementations, the report output module 16 may specifically include: The first report output unit is used to perform a compatibility analysis on the current interface definition file set according to a preset compatibility judgment rule if the structure of the current interface definition file set changes, so as to identify the preset compatible change items and preset incompatible change items in the current interface definition file set. If the preset incompatible change items exist, the current interface definition file set is determined to be incompatible, and a corresponding compatibility report is output. The second report output unit is used to perform compatibility analysis on each semantic change in the semantic change list according to the preset compatibility judgment rules if there is any inconsistency in the version identification information, so as to identify the preset compatible change items and preset incompatible change items in each semantic change. If there are preset incompatible change items, the current interface definition file set is determined to be incompatible, and the corresponding compatibility report is output.

[0064] In some specific implementations, the version tag generation module 17 may specifically include: The code generation unit is used to generate target code based on the current interface definition file set and preset configuration parameters using a preset code generation tool. A code submission unit is used to submit the target code to the target branch of the target repository in an atomic submission manner; The status update unit is used to update the synchronization status in the historical interface record to a preset synchronization completion status, and record the submission hash value and synchronization time. The tag creation unit is used to automatically increment the version number of the target code when the target branch meets the preset main branch determination conditions, so as to create a corresponding version tag for the target repository.

[0065] Furthermore, embodiments of this application also disclose an electronic device, Figure 3This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the version management method for interface definition files disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0066] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0067] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0068] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the version management method for the interface definition file executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0069] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned version management method for interface definition files. The specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0070] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0071] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0072] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0073] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0074] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A version management method for interface definition files, characterized in that, include: Obtain the current set of interface definition files and the corresponding historical interface records; wherein, the current set of interface definition files includes the main interface file and the dependent interface files, the dependent interface files are obtained by recursively identifying the dependency statements of the main interface file, and cyclic dependency detection is performed during the recursive identification process, the accessed file paths are recorded, and when an accessed file is encountered, a warning message is recorded and processing continues; the historical interface records include the file path information, version identification information and historical semantic feature mapping of the historical interface definition files; Perform structural difference detection on the current set of interface definition files and the historical interface records to determine whether the structural composition of the current set of interface definition files has changed; If the structure of the current set of interface definition files changes, it is determined that the interface definition has been changed; If the structure of the current set of interface definition files has not changed, then determine whether the version identification information corresponding to the main interface file and the dependent interface files is consistent; If there is a discrepancy in the version identification information, the corresponding current semantic feature mapping is extracted based on the abstract syntax tree of the current interface definition file set, and the current semantic feature mapping is compared with the historical semantic feature mapping to generate a corresponding semantic change list. According to the preset compatibility judgment rules, a compatibility analysis is performed on each semantic change in the semantic change list or the current interface definition file set, a corresponding compatibility report is output, and it is determined that there are changes to the interface definition. When the interface definition changes, a preset code generation tool is invoked to generate target code based on the current set of interface definition files and publish it to the target repository, update the historical interface records, and generate a corresponding version tag for the target repository.

2. The version management method for interface definition files according to claim 1, characterized in that, Retrieve historical API records, including: Receive the interface synchronization request of the current set of interface definition files; the interface synchronization request includes any one or more of the following: repository address, repository branch name, and service name of the historical interface definition files; Parsing the warehouse address yields the group to which the target warehouse belongs and the name of the target warehouse; Call the preset API to obtain the historical interface definition file corresponding to the repository branch name, and obtain the version identification information of the historical interface definition file; The dependency statements of the historical main interface files in the historical interface definition file are parsed to recursively identify all dependency files and construct the corresponding dependency file list; Based on the version identification information in the historical interface definition file, a historical semantic feature mapping is constructed; By integrating the target repository's group, the target repository name, the version identifier information, the dependency file list, and the historical semantic feature mapping, historical interface records are obtained.

3. The version management method for interface definition files according to claim 1, characterized in that, The step of performing structural difference detection on the current interface definition file set and the historical interface records to determine whether the structural composition of the current interface definition file set has changed includes: Determine whether the current set of interface definition files is consistent with the main interface file path corresponding to the historical interface record, and whether the number of dependent interface files and the set of file paths of the current set of interface definition files and the historical interface record are equal; If the main interface file paths are consistent and the number of files is equal to the set of file paths, then it is determined that the structural composition has not changed. If the main interface file paths are inconsistent and / or the number of files is not equal to the set of file paths, then it is determined that the structural composition has changed.

4. The version management method for interface definition files according to claim 1, characterized in that, The step of determining whether the version identification information corresponding to the main interface file and the dependent interface files are consistent includes: By comparing the hash values ​​of the main interface files in the current set of interface definition files and the respective main interface files in the historical interface records, the first comparison result is obtained; The dependent interface files in the current interface definition file set are sorted according to a preset file path order to obtain the first file sequence; The historical dependency records in the historical interface records are sorted according to the preset file path order to obtain the second file sequence; The version identification information of the first file sequence and the second file sequence are compared to obtain a second comparison result; If the first comparison result and / or the second comparison result indicate that the hash values ​​are inconsistent, then the version identification information is determined to be inconsistent. If the hash values ​​represented by the first comparison result and the second comparison result are consistent, then the version identification information is determined to be consistent. If the version identification information is consistent, it is determined that the current set of interface definition files has not changed, and the process ends directly.

5. The version management method for interface definition files according to claim 1, characterized in that, The abstract syntax tree based on the current interface definition file set is used to extract the corresponding current semantic feature map, and the current semantic feature map is compared with the historical semantic feature map to generate a corresponding semantic change list, including: The current interface definition file set is parsed to construct an abstract syntax tree, and the corresponding current semantic feature mapping is extracted based on the abstract syntax tree; wherein, the semantic feature mapping includes any one or more of service-level features, method-level features, and field-level features; The current semantic feature map is compared with the historical semantic feature map to identify semantic change items of each change type; wherein, the change type includes addition, deletion, modification and sequence change; The semantic change details of each of the semantic change items are detected to generate a corresponding semantic change list; the semantic change list includes any one or more of the change type, change level, change location, value before change, and value after change.

6. The version management method for interface definition files according to claim 1, characterized in that, The process involves performing compatibility analysis on each semantic change in the semantic change list or the current interface definition file set according to preset compatibility judgment rules, and outputting a corresponding compatibility report, including: If the structure of the current interface definition file set changes, a compatibility analysis is performed on the current interface definition file set according to the preset compatibility judgment rules to identify the preset compatible changes and preset incompatible changes in the current interface definition file set. If the preset incompatible changes exist, the current interface definition file set is determined to be incompatible, and a corresponding compatibility report is output. If there is an inconsistency in the version identification information, then according to the preset compatibility judgment rules, a compatibility analysis is performed on each semantic change in the semantic change list to identify the preset compatible change items and preset incompatible change items in each semantic change. If there is a preset incompatible change item, then the current interface definition file set is determined to be incompatible, and a corresponding compatibility report is output.

7. The version management method for interface definition files according to claim 1, characterized in that, The process of calling a preset code generation tool to generate target code based on the current set of interface definition files and publishing it to the target repository, updating the historical interface records, and generating corresponding version tags for the target repository includes: Using a preset code generation tool, target code is generated based on the current interface definition file set and preset configuration parameters; The target code is submitted to the target branch of the target repository using an atomic commit method; Update the synchronization status in the historical interface record to the preset synchronization completion status, and record the submission hash value and synchronization time; When the target branch meets the preset main branch determination conditions, the version number of the target code is automatically incremented to create a corresponding version tag for the target repository.

8. A version management device for interface definition files, characterized in that, include: The record acquisition module is used to acquire the current set of interface definition files and the corresponding historical interface records. The current set of interface definition files includes the main interface file and the dependent interface files. The dependent interface files are obtained by recursively identifying the dependency statements of the main interface file. During the recursive identification process, cyclic dependency detection is performed, and the accessed file paths are recorded. When an accessed file is encountered, a warning message is recorded and processing continues. The historical interface records include the file path information, version identification information, and historical semantic feature mapping of the historical interface definition files. The first file judgment module is used to perform structural difference detection on the current interface definition file set and the historical interface records to determine whether the structural composition of the current interface definition file set has changed; The first file determination module is used to determine that the interface definition has changed if the structure of the current interface definition file set has changed. The second file judgment module is used to determine whether the version identification information corresponding to the main interface file and the dependent interface file is consistent if the structure of the current interface definition file set has not changed. The second file determination module is used to extract the corresponding current semantic feature mapping based on the abstract syntax tree of the current interface definition file set if there is a discrepancy in the version identification information, and compare the current semantic feature mapping with the historical semantic feature mapping to generate a corresponding semantic change list. The report output module is used to perform compatibility analysis on each semantic change in the semantic change list or the current interface definition file set according to preset compatibility judgment rules, output the corresponding compatibility report, and determine that there are changes in the interface definition; The version tag generation module is used to call a preset code generation tool to generate target code based on the current set of interface definition files and publish it to the target repository when the interface definition changes, update the historical interface records, and generate corresponding version tags for the target repository.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the version management method for interface definition files as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer program is executed by a processor, it implements the version management method for interface definition files as described in any one of claims 1 to 7.

Images