Version management method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a version management method and device, electronic equipment and a storage medium, and relates to the technical field of databases, such as the field of distributed databases. The method comprises the following steps: determining a to-be-released version and a plurality of corresponding to-be-repaired defects; for each to-be-repaired defect, if the repair of the release branch of the to-be-repaired defect on the to-be-released version is completed, updating the defect repair state of the to-be-repaired defect on the to-be-released version from a to-be-repaired state to a to-be-released state; the to-be-repaired defect with the defect repair state updated to the to-be-released state in the multiple to-be-repaired defects serves as a first defect; and if the release condition corresponding to the to-be-released version is met, releasing the release branches corresponding to the to-be-released version, releasing the first defects along with the release branches, and updating the defect repair state of each first defect in the to-be-released version from a to-be-released state to a repaired state. According to the embodiment of the invention, the version management efficiency is improved.

Description

Technical Field

[0001] The present disclosure relates to the field of database technology, and in particular to a version management method, device, electronic device and storage medium. Background Art

[0002] As software projects grow in size, complexity, and iteration frequency, software version management becomes particularly critical. Currently, traditional version control systems, such as Git (an open source distributed version control system) and task management tools, such as JIRA (a project and transaction tracking tool) and GitHub Issues (a feature in Github for tracking and managing software projects), are widely used solutions in the industry for managing software versions and defects.

[0003] Existing version management tools can achieve simple single-version management, but when the number of versions increases, R&D personnel are required to perform a lot of manual operations to repeatedly copy and associate defects, which consumes a lot of manpower and time and is inefficient. Summary of the invention

[0004] The embodiments of the present disclosure provide a version management method, device, electronic device and storage medium, which can solve the problem of low efficiency of existing version management methods. The technical solutions provided by the present disclosure are as follows: According to one aspect of an embodiment of the present disclosure, a version management method is provided, which is applied to a management system, and the method includes: Determine a version to be released, and a plurality of defects to be fixed in the version to be released, wherein the defect fixing status of the defects to be fixed on the version to be released is a to-be-fixed status; For each defect to be fixed, if the repair of the defect to be fixed in the release branch of the version to be released has been completed, update the defect repair status of the defect to be fixed in the version to be released from the state to be fixed to the state to be released; updating a defect to be fixed whose defect repair status is to be released among the multiple defects to be fixed as a first defect; If the release conditions corresponding to the version to be released are met, the release branch corresponding to the version to be released is released, each first defect is released along with the release branch, and each first defect is updated in the defect repair status of the version to be released from the to-be-released state to the fixed state.

[0005] Optionally, the management system is used to manage associated systems; If the repair of the release branch of the to-be-repaired defect on the to-be-released version has been completed, updating the defect repair status of the to-be-repaired defect on the to-be-released version from a to-be-repaired status to a to-be-released status, comprises: If it is determined based on the trunk repair event for the defect to be repaired that the defect to be repaired has been repaired on the trunk, then the defect repair status of the defect to be repaired on the version to be released is updated from the to-be-repaired status to the trunk repaired status; The trunk repair event of the defect to be repaired is triggered when the associated system receives a trunk repair for the original defect entity corresponding to the defect to be repaired; the trunk repair event includes information about the defect to be repaired; Based on at least one associated version corresponding to the defect to be fixed, create a branch repair of a release branch corresponding to each associated version; Determine a target associated version from each associated version; the target associated version includes the version to be released; For each target associated version, based on the branch repair of the release branch of the target associated version, the release branch of the target associated version is repaired, and the defect repair status of the defect to be repaired on the target associated version is updated from the trunk repaired status to the to-be-released status.

[0006] Optionally, the method further comprises: taking defects other than the first defect among the multiple defects to be fixed in the to-be-released version as second defects; After the next version corresponding to the to-be-released version is created, the next version is used as the associated version corresponding to each second defect, and the defect repair status of each second defect on the next version is set to a to-be-repaired status; The next version corresponding to the version to be released is a version obtained by updating the version to be released.

[0007] Optionally, the method further comprises: If a defect creation event for the version to be released sent by the associated system is received, determining a third defect newly added in the version to be released based on the defect creation event; For each third defect, at least one associated version corresponding to the third defect is obtained, and a defect repair state of the third defect on each corresponding associated version is set to a to-be-repaired state; the at least one associated version includes the to-be-released version.

[0008] Optionally, the determining that the defect to be repaired has been repaired on the trunk based on the trunk repair event for the defect to be repaired includes: In response to a defect closing event for the defect to be fixed, determining that the defect to be fixed has been fixed on the trunk of the version to be released; The defect closing event for the defect to be repaired is triggered after each trunk repair event corresponding to the defect to be repaired.

[0009] Optionally, the multiple defects to be fixed in the version to be released are determined based on the following method: Obtaining a plurality of initial defects related to the version to be released; For each initial defect, if the admission permission information of the initial defect on the version to be released is admission, and the defect repair status of the initial defect on the version to be released is pending repair, the initial defect is used as the pending repair defect of the version to be released.

[0010] Optionally, the method further comprises: In response to the to-be-released version creation event, create the to-be-released version and the release branch corresponding to the to-be-released version, and set the version status of the to-be-released version to the active status; The step of releasing the release branch corresponding to the to-be-released version further includes: The version status of the to-be-released version is updated from the active status to the released status.

[0011] Optionally, the association system includes multiple original defect entities, multiple original repair entities and multiple original version entities; the multiple defects to be managed in the management system include multiple defect concept entities corresponding to the multiple original defect entities respectively; the multiple repairs to be managed in the management system include multiple repair concept entities corresponding to the multiple original repair entities respectively; the multiple versions to be managed in the management system include multiple version concept entities corresponding to the multiple original version entities respectively; The status updates of the entities in the association system and the conceptual entities to which the entities correspond in the management system are synchronized.

[0012] According to another aspect of an embodiment of the present disclosure, there is provided a version management device, the device comprising: A determination module, used to determine a version to be released, and a plurality of defects to be fixed in the version to be released, wherein the defect repair status of the defect to be fixed on the version to be released is a to-be-fixed status; A status update module is used to update the defect repair status of each defect to be repaired on the version to be released from a to-be-repaired state to a to-be-released state if the repair of the defect to be repaired on the release branch of the version to be released has been completed; A first defect determination module, configured to update a defect to be repaired whose defect repair status is updated to a to-be-released status among the multiple defects to be repaired as a first defect; The version release module is used to release the release branch corresponding to the version to be released if the release conditions corresponding to the version to be released are met, release each first defect along with the release branch, and update the defect repair status of each first defect in the version to be released from the to-be-released state to the fixed state.

[0013] According to another aspect of an embodiment of the present disclosure, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of any one of the above-mentioned version management methods when executing the program.

[0014] According to another aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned version management methods are implemented.

[0015] According to one aspect of an embodiment of the present disclosure, a computer program product is provided, which includes a computer program, and when the computer program is executed by a processor, the steps of any one of the above-mentioned version management methods are implemented.

[0016] The technical solution provided by the embodiments of the present disclosure has the following beneficial effects: For each defect to be fixed in the version to be released, by setting the defect repair status of the defect to be fixed on the version to be released, and automatically updating the defect repair status of the defect to be fixed on the version to be released in real time, the defect repair status of each defect on each version is tracked. Especially for the scenario of multi-version management, when the number of versions increases, the number of defects that need to be managed will also increase significantly. Compared with the existing version management tools that require R&D personnel to manually update and align the repair progress of each defect on each version, the version management method provided by the embodiment of the present disclosure does not require R&D personnel to manually update and align the defect repair status of each defect on each version, saving a lot of manpower costs and time, and improving the efficiency of version management.

[0017] Furthermore, the first defect that has been repaired is automatically determined according to the defect repair status of each defect to be repaired in the version to be released, and the first defect is released along with the release branch, thereby realizing the automatic release of the version to be released and improving the efficiency of version release; at the same time, it avoids the impact of operational errors or omissions of R&D personnel on the version quality and ensures the quality of the released version. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, the drawings required for describing the embodiments of the present disclosure are briefly introduced below.

[0019] Figure 1 A schematic diagram of an application scenario of the version management method provided in an embodiment of the present disclosure; Figure 2 A schematic diagram of entity state synchronization between systems provided by an embodiment of the present disclosure; Figure 3 A schematic diagram of a process flow of a version management method provided in an embodiment of the present disclosure; Figure 4 A schematic diagram of entity status update provided by an embodiment of the present disclosure; Figure 5 A schematic diagram of a release process provided by an embodiment of the present disclosure; Figure 6 A schematic diagram of a version view provided for an embodiment of the present disclosure; Figure 7 A schematic diagram of a defect view provided by an embodiment of the present disclosure; Figure 8 A schematic diagram of a process of creating a version provided in an embodiment of the present disclosure; Fig. 9 A schematic diagram of a process of creating a defect provided by an embodiment of the present disclosure; Fig.10 A schematic diagram of a trunk repair process provided by an embodiment of the present disclosure; Fig.11 A schematic diagram of a branch repair process provided by an embodiment of the present disclosure; Fig.12 A schematic diagram of a process of version release provided in an embodiment of the present disclosure; Fig.13 A schematic diagram of the structure of a version management device provided by an embodiment of the present disclosure; Fig.14 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0020] The embodiments of the present disclosure are described below in conjunction with the drawings in the present disclosure. It should be understood that the implementation methods described below in conjunction with the drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present disclosure and do not constitute a limitation on the technical solutions of the embodiments of the present disclosure.

[0021] It will be understood by those skilled in the art that, unless specifically stated, the singular forms "one", "said", and "the" used herein may also include plural forms. It should be further understood that the terms "including" and "comprising" used in the embodiments of the present disclosure refer to that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements and / or components, but do not exclude the implementation as other features, information, data, steps, operations, elements, components and / or combinations thereof supported by the technical field. It should be understood that when we say that an element is "connected" or "coupled" to another element, the one element may be directly connected or coupled to the other element, or it may refer to that the one element and the other element establish a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein indicates at least one of the items defined by the term, for example, "A and / or B" or "A, B" indicates that it is implemented as "A", or implemented as "B", or implemented as "A and B".

[0022] In order to make the objectives, technical solutions and advantages of the present disclosure more clear, the embodiments of the present disclosure will be further described in detail below with reference to the accompanying drawings.

[0023] In the field of software development, continuous integration (CI) and continuous deployment (CD) frameworks are now widely used to support rapid software development and iteration. The core of these frameworks is to be able to continuously and automatically build, test and release software to adapt to the rapid changes in the market and technology. For managing software versions and defects, traditional version control systems such as Git (an open source distributed version control system) and task management tools such as JIRA (a project and transaction tracking tool) and GitHub Issues (a function in Github for tracking and managing software projects) are widely used solutions in the industry. They provide developers with basic functions for tracking code changes, managing tasks and defects. The use of these tools, especially in multi-version and multi-branch project management, is an important part of the modern software development process.

[0024] In large-scale local deployment software projects, especially database systems like TiDB (a distributed database), version management becomes particularly critical. TiDB is a fast-iterating database software, usually released at a cadence of five to six major versions per year. Each released major version has a three-year life cycle. As TiDB continues to develop and iterate, new functional, performance, and security defects will continue to be discovered. These problems may also exist in the released major versions and affect the actual use of users. For this reason, it is necessary to continuously merge the necessary fixes back to the main version that is still in its life cycle in the form of patches, and release patch versions as needed.

[0025] During the continuous development and iteration of software, new software versions are continuously released. Effective version management must be able to handle multiple active versions, which usually involves code merging and rollback operations across multiple branches to ensure that all critical fixes are applied to all affected versions in a timely and accurate manner.

[0026] Systems such as GitHub Issues and JIRA provide bug tracking and task management capabilities, enabling teams to record issues, discuss solutions, and track the progress of fixes. These tools usually require developers and project managers to invest a lot of time in manual operations and data synchronization, especially in scenarios involving multiple software versions. This manual process is often complex and error-prone.

[0027] The existing version management methods have the following problems: Version defects are difficult to manage: There are usually a large number of main versions in their life cycle. R&D personnel need to spend a lot of energy and time to sort out the repair status of all defects that affect the version, analyze and handle them one by one to ensure the timely release of the version. If they are not careful, defects may be missed, thus affecting the quality of the version.

[0028] Defect repair is difficult to determine: A defect may affect multiple versions and may correspond to multiple repair patches. It is difficult for R&D personnel to confirm the progress of defect resolution on a certain branch.

[0029] Difficulty in personnel collaboration: A defect requires the attention of different personnel at different stages. Since it is difficult to determine the stage of defect repair, it is difficult for each responsible person to know when they should intervene in the handling of which defects.

[0030] The version management method, device, electronic device and storage medium provided by the present disclosure are intended to solve at least one of the above technical problems in the prior art.

[0031] The following describes several exemplary embodiments to illustrate the technical solutions of the embodiments of the present disclosure and the technical effects produced by the technical solutions of the present disclosure. It should be noted that the following embodiments can refer to, draw on or combine with each other, and the same terms, similar features and similar implementation steps in different embodiments will not be described repeatedly.

[0032] Figure 1 A schematic diagram of an application scenario of the version management method provided in the embodiment of the present disclosure, such as Figure 1 As shown, the application scenario includes a management system and an associated system. The management system is used to manage the associated system, and the associated system can be any version control system with defect, repair, and branch entity concepts, such as Gitlab and Github.

[0033] The associated system includes multiple original defect entities, multiple original repair entities and multiple original version entities; the multiple defects to be managed in the management system include multiple defect concept entities corresponding to the multiple original defect entities; the multiple repairs to be managed in the management system include multiple repair concept entities corresponding to the multiple original repair entities; the multiple versions to be managed in the management system include multiple version concept entities corresponding to the multiple original version entities; The status updates of each original entity in the association system and each conceptual entity corresponding to each original entity in the management system are synchronized.

[0034] Specifically, the associated system can be an existing version management system, such as Github (a hosting platform for software projects), and the associated system can include multiple original defect entities (i.e., issues), multiple original fix entities (i.e., PullRequests), and multiple original version entities (i.e., versions). Among them, "defects" usually refer to errors or problems in the software, "fixes" are direct responses to these problems, and "versions" include a series of specific functional enhancements and defect fixes.

[0035] The management system is used to manage associated systems. For each entity in the associated system, there is a corresponding conceptual entity in the management system. A conceptual entity refers to an entity of a conceptual type. For multiple original defect entities in the associated system, the management system includes multiple defect conceptual entities corresponding to each original defect entity, that is, multiple defects to be managed. For multiple original repair entities in the associated system, the management system includes multiple repair conceptual entities corresponding to each original repair entity, that is, multiple repairs to be managed. For multiple original version entities in the associated system, the management system includes multiple version conceptual entities corresponding to each original version entity, that is, multiple versions to be managed.

[0036] like Figure 1As shown, there is a one-to-one correspondence between each original entity in the association system and the multiple conceptual entities corresponding to each original entity in the management system, and the status updates of each original entity in the association system and the conceptual entities corresponding to each original entity in the management system are synchronized.

[0037] Figure 2 A schematic diagram of entity state synchronization between systems provided by an embodiment of the present disclosure, such as Figure 2 As shown in the figure, the entity state synchronization process between systems includes: When the R&D personnel directly operate the original entity in the associated system (such as creating a fix, closing a defect), the state of the original entity will change. The associated system will send the entity change event to the management system interface through a request. The management system receives the event, processes the state of the conceptual entity corresponding to the original entity in the management system, and stores the latest state. At the same time, if other related entities have an indirect state change due to the event, the management system will synchronize the state change to the original entity corresponding to the related entity in the associated system.

[0038] When R&D personnel operate on a conceptual entity in the management system and the operation affects the entity status, the management system updates and stores the status of the conceptual entity targeted by the operation, and simultaneously synchronously updates the status of the original entity corresponding to the conceptual entity in the associated system.

[0039] By managing the two-way response between the entities in the corresponding relationship in the management system and the associated system, the state consistency between the entities in the corresponding relationship in the two systems is guaranteed.

[0040] Figure 3 A schematic diagram of a version management method provided in an embodiment of the present disclosure is provided. The method is applied to a management system, such as Figure 3 As shown, the method includes: Step S110 , determining a version to be released and a plurality of defects to be fixed in the version to be released, wherein the defect fixing status of the defects to be fixed in the version to be released is a to-be-fixed status.

[0041] Specifically, the version management method provided in the embodiment of the present disclosure is applied to a management system. Therefore, the objects operated by the management system in the version management method provided in the embodiment of the present disclosure are all conceptual entities in the management system.

[0042] The version to be released may be a version that needs to be released in the management system, and the multiple defects to be fixed in the version to be released may be multiple unfixed defects related to the version to be released, and the defect repair status of each defect to be fixed on the version to be released is a to-be-fixed status. The number of versions to be released may be one or more, and when the number of versions to be released is multiple, the method provided in the embodiment of the present disclosure may be executed for each version to be released.

[0043] It should be noted that the defect repair status of each defect in the management system is for a specific version, that is, the defect repair status of the same defect in different versions can be the same or different. The defect repair status of a defect in a certain version can be used to represent the defect repair status of the defect in that version.

[0044] Step S120, for each defect to be fixed, if the repair of the release branch of the defect to be fixed on the version to be released has been completed, the defect repair status of the defect to be fixed on the version to be released is updated from the state to be fixed to the state to be released; Step S130: update the defect repair status of the multiple defects to be repaired to the to-be-released status as the first defect.

[0045] Specifically, for each defect to be fixed in the version to be released, if the management system detects that the repair of the defect to be fixed on the release branch of the version to be released has been completed, it means that the defect to be fixed has been repaired in the trunk of the version to be released, and the repair of the defect to be fixed has been merged into the release branch of the version to be released, then the defect repair status of the repair defect in the version to be released can be updated from the to-be-fixed status to the to-be-released status.

[0046] Among the multiple defects to be fixed in the version to be released, the defect to be fixed whose corresponding defect repair status is updated to the to-be-released status is taken as the first defect, that is, the first defect can be released along with the release branch.

[0047] Step S140, if the release condition corresponding to the version to be released is met, the release branch corresponding to the version to be released is released, each first defect is released along with the release branch, and the defect repair status of each first defect in the version to be released is updated from the to-be-released state to the repaired state.

[0048] Specifically, when the management system detects that the version to be released meets the corresponding release conditions, it can release the release branch corresponding to the version to be released. At the same time, each first defect is distributed along the release branch, and the defect repair status of each first defect in the version to be released is updated from the to-be-released state to the fixed state.

[0049] Optionally, there is a preset release time corresponding to the version to be released. When the preset release time corresponding to the version to be released is reached, it is determined that the release condition corresponding to the version to be released is met, wherein the preset release time may be a moment or a time period. It may also be determined that the release condition corresponding to the version to be released is met when a version release instruction for the version to be released is received from the release manager; it may also be determined that the release condition corresponding to the version to be released is met when the preset time period corresponding to the version to be released is reached and a version release instruction for the version to be released is received from the release manager. The embodiment of the present disclosure does not specifically limit the release condition.

[0050] In the disclosed embodiment, for each defect to be fixed in the version to be released, by setting the defect repair status of the defect to be fixed on the version to be released, and automatically updating the defect repair status of the defect to be fixed on the version to be released in real time, the defect repair status of each defect on each version is tracked. Especially for the scenario of multi-version management, when the number of versions increases, the number of defects to be managed will also increase significantly. Compared with the existing version management tools that require R&D personnel to manually update and align the repair progress of each defect on each version, the version management method provided by the disclosed embodiment does not require R&D personnel to manually update and align the defect repair status of each defect on each version, saving a lot of manpower costs and time, and improving the efficiency of version management.

[0051] Furthermore, the first defect that has been repaired is automatically determined according to the defect repair status of each defect to be repaired in the version to be released, and the first defect is released along with the release branch, thereby realizing the automatic release of the version to be released and improving the efficiency of version release; at the same time, it avoids the impact of operational errors or omissions of R&D personnel on the version quality and ensures the quality of the released version.

[0052] As an optional embodiment, the management system is used to manage the associated system; If the repair of the defect to be fixed in the release branch of the version to be released has been completed, the defect repair status of the defect to be fixed in the version to be released is updated from the status of being fixed to the status of being released, including: If it is determined based on the trunk repair event for the defect to be repaired that the defect to be repaired has been repaired on the trunk, the defect repair status of the defect to be repaired on the version to be released is updated from the to-be-repaired status to the trunk repaired status; the trunk repair event for the defect to be repaired is triggered when the associated system receives the trunk repair for the original defect entity corresponding to the defect to be repaired; the trunk repair event includes the information of the defect to be repaired; Based on at least one associated version corresponding to the defect to be fixed, create a branch fix for the release branch corresponding to each associated version; Determine a target associated version from each associated version; the target associated version includes a version to be released; For each target-related version, based on the branch repair of the release branch of the target-related version, the release branch of the target-related version is repaired, and the defect repair status of the defect to be repaired on the target-related version is updated from the trunk fixed status to the to-be-released status.

[0053] Specifically, for each defect to be repaired, there is an original defect entity corresponding to the defect to be repaired in the associated system. The R&D personnel can create a trunk repair for the original defect entity in the associated system. After the trunk repair is completed, the associated system will send a trunk repair event for the defect to be repaired to the management system. The trunk repair event may include information about the defect to be repaired.

[0054] A defect can correspond to multiple repair operations. When the management system receives all trunk repair events corresponding to the defect to be repaired, it can be determined that the defect to be repaired has been repaired on the trunk, and then the defect repair status of the defect to be repaired in the version to be released is updated from the to-be-repaired status to the trunk fixed status.

[0055] The defect to be fixed can be associated with multiple versions, and based on at least one associated version corresponding to the defect to be fixed, branch fixes for release branches corresponding to each associated version can be automatically created. The associated version corresponding to the defect can be the version affected by the defect, such as the version containing the defect.

[0056] For multiple associated versions corresponding to the defect to be fixed, a target associated version can be selected from the multiple associated versions, and the target associated version includes the version to be released.

[0057] Optionally, all associated versions may be used as target associated versions; or some associated versions may be used as target associated versions. For example, after multiple associated versions are determined, the multiple associated versions may be presented to the reviewer, and based on the reviewer's selection operation on the multiple associated versions (for example, some versions may not be planned to be released in the near future), the associated version selected by the reviewer is used as the target associated version.

[0058] After determining the target associated version, the trunk fix of the defect to be fixed in the to-be-released version can be merged into the release branch of the defect to be fixed in the target associated version, completing the branch repair of the defect to be fixed on the release branch of the target associated version, and updating the defect repair status of the defect to be fixed on the target associated version from the trunk fixed status to the to-be-released status.

[0059] It should be noted that the creation of branch repairs for release branches of each associated version and the completion of branch repairs for release branches of each target associated version can be implemented on the management system or on the associated system, but no matter the operation is on the conceptual entity in the management system or the original entity in the associated system, it needs to be synchronized to the corresponding entity in the other side system to maintain the consistency between the entities in the management system and the associated system that have a corresponding relationship. In the disclosed embodiment, based on the operation events of the original defect entity corresponding to the defect to be repaired in the associated system, the defect repair status of the defect to be repaired in the management system on the version to be released is automatically updated in real time, thereby realizing the tracking of the defect repair status of each defect on each version, while maintaining the status consistency between each conceptual entity corresponding to each original entity in the associated system in the management system.

[0060] Furthermore, by establishing an association between defects and versions, after the trunk repair of the defect is completed, branch repairs of release branches of multiple associated versions related to the defect can be automatically created, and branch repairs of release branches of multiple target associated versions can be automatically completed, thereby realizing automatic branch repairs of multiple versions related to the defect, greatly reducing the workload of R&D personnel; in the scenario of multi-version management, it can effectively advance the progress of defect repairs on multiple versions and improve the efficiency of version release.

[0061] As an optional embodiment, the method further includes: Defects other than the first defect among the multiple defects to be fixed in the version to be released are taken as second defects; After the next version corresponding to the version to be released is created, the next version is used as the associated version corresponding to each second defect, and the defect repair status of each second defect on the next version is set to a to-be-repaired status; The next version corresponding to the version to be released is a version obtained by updating the version to be released.

[0062] Specifically, for multiple defects to be fixed in the version to be released, the defects except the first defect in the multiple defects to be fixed are taken as the second defects, that is, the second defect is not in the to-be-released state in the defect repair state of the version to be released, and the second defect will not be released with the release branch of the version to be released.

[0063] There is inheritance between the various versions of the software, that is, the later released version will improve the previous version. The version obtained after updating the version to be released will be regarded as the next version of the version to be released.

[0064] For example, if the version number of the version to be released is 7.2.5, then the version number of the next version to be released is 7.2.6. In other words, if the version number of the version to be released is expressed as major version number-minor version number-revision number, then the major version number and minor version number of the version to be released and its corresponding next version are the same, and the revision number of the next version is 1 greater than the revision number of the version to be released.

[0065] Since the second defects are not released with the release branch of the version to be released, after the next version of the version to be released is created, the next version can inherit these second defects from the version to be released and continue to fix these second defects. In other words, these second defects are related to the next version of the version to be released.

[0066] For each second defect, the next version of the version to be released can be used as the associated version corresponding to the second defect, and the defect repair state of the second defect in the next version is set to the to-be-repaired state. For example, the version identifier of the next version can be added to the version association information corresponding to the second defect.

[0067] It should be noted that when the previous version of the version to be released is released, the previous version can be used as the version to be released in the previous version release operation, and the version to be released can be used as the next version in the previous version release operation. According to the above steps, the association relationship between the version to be released and multiple defects can be automatically established.

[0068] In the disclosed embodiment, for the second defect that the next version inherits from the version to be released but has not been completely repaired, the next version is automatically associated with the second defect, thereby automatically establishing an association relationship between the defect and the version. There is no need for R&D personnel to manually add the defect-corresponding associated version identifier, which reduces the workload of R&D personnel, saves a lot of manpower costs and time, and improves efficiency.

[0069] As an optional embodiment, the method further includes: If a defect creation event for the version to be released sent by the associated system is received, determining a third defect newly added in the version to be released based on the defect creation event; For each third defect, at least one associated version corresponding to the third defect is obtained, and a defect repair state of the third defect on each corresponding associated version is set to a to-be-repaired state; the at least one associated version includes a to-be-released version.

[0070] Specifically, for a new version to be released, there may be some new defects. For the version to be released, the R&D personnel can create a new original defect entity for the version to be released in the associated system, and send the corresponding defect creation event to the management system. Based on the received defect creation event, the management system can create a defect concept entity corresponding to the new original defect entity, that is, the third defect.

[0071] For each newly added third defect, the third defect may be associated with multiple versions, and at least one associated version corresponding to the third defect may be obtained, and the defect repair status of the third defect on each corresponding associated version may be set to a to-be-repaired status. The at least one associated version corresponding to the third defect includes a to-be-released version.

[0072] Optionally, for each defect to be managed in the management system, the defect to be managed may include corresponding associated version information, and the associated version information may include version identifiers corresponding to at least one version related to the defect to be managed.

[0073] For each third defect, the version identifier corresponding to at least one associated version related to the third defect can be obtained, and the version identifier corresponding to each associated version can be added to the associated version information corresponding to the third defect. The version identifier corresponding to at least one associated version related to the third defect can be determined by the R&D personnel in the management system.

[0074] For example, for each newly added defect, the R&D personnel can mark multiple version identifiers related to the defect on the defect in the management system.

[0075] In the embodiment of the present disclosure, based on the defect creation event for the version to be released sent by the associated system, the management system synchronously adds a third defect corresponding to the version to be released, and establishes an association relationship between the newly added third defect and multiple versions, so as to facilitate subsequent version management based on the association relationship between the defect and the version.

[0076] As an optional embodiment, determining that the defect to be repaired has been repaired on the trunk based on the trunk repair event for the defect to be repaired includes: In response to a defect closing event for a defect to be fixed, determining that the defect to be fixed has been fixed on the trunk of the version to be released; The defect closing event for the defect to be repaired is triggered after each trunk repair event corresponding to the defect to be repaired.

[0077] Specifically, for each defect to be repaired, the defect to be repaired corresponds to multiple trunk repair operations. After the multiple trunk repairs corresponding to the defect to be repaired are completed, a defect closing event for the defect to be repaired can be triggered.

[0078] Optionally, the associated system may automatically trigger a defect closure event for the defect to be repaired after receiving all trunk repair operations for the defect to be repaired, or the R&D personnel may create a defect closure event for the defect to be repaired after determining that the trunk repair of the defect to be repaired in the associated system has been completed. The associated system sends the generated defect closure event to the management system.

[0079] Optionally, after receiving all trunk repair events corresponding to the defect to be repaired, the management system can determine that the defect to be repaired has been repaired on the trunk and automatically trigger a defect closing event for the defect to be repaired, or after the management system receives all trunk repair events corresponding to the defect to be repaired, the R&D personnel confirm on the management system that the defect to be repaired has been repaired on the trunk and create a defect closing event for the defect to be repaired.

[0080] It should be noted that the defect closing event can be generated on the management system or on the associated system. However, no matter the operation is on the conceptual entity in the management system or the original entity in the associated system, it needs to be synchronized to the corresponding entity in the other system to maintain the consistency between the entities in the management system and the associated system that have a corresponding relationship.

[0081] Based on the defect closing event for the defect to be fixed, the management system can determine that the trunk repair of the defect to be fixed has been completed, and then the defect repair status of the defect to be fixed in the version to be released can be updated from the to-be-fixed status to the trunk fixed status, thereby realizing real-time automatic update of the defect repair status of the defect in each version in the management system.

[0082] As an optional embodiment, the multiple defects to be fixed in the version to be released are determined based on the following method: Get a number of initial defects related to the version to be released; For each initial defect, if the admission permission information of the initial defect on the version to be released is admission, and the defect repair status of the initial defect on the version to be released is pending repair, the initial defect is used as the pending repair defect of the version to be released.

[0083] Specifically, the management system includes a plurality of defects to be managed, and the defects to be managed may include corresponding associated version information, and the associated version information may include version identifiers corresponding to at least one version related to the defects to be managed.

[0084] From among the multiple defects to be managed in the management system, the defect to be managed whose associated version information includes a version identifier corresponding to the version to be released can be taken as an initial defect related to the version to be released.

[0085] Among them, the multiple initial defects related to the version to be released include the unrepaired defects inherited by the version to be released from the corresponding previous version, as well as the new defects in the version to be released. The establishment of the association relationship between defects and versions can be referred to the records of the corresponding embodiments above, and will not be repeated here.

[0086] After obtaining multiple initial defects related to the version to be released, the initial defects whose access permission information on the version to be released is access and whose defect repair status on the version to be released is to be repaired can be selected from the multiple initial defects as the defects to be repaired of the version to be released.

[0087] Among them, the admission permission information of the initial defect in the version to be released can be used to characterize the admission status of the initial defect in the version to be released. The admission permission information may include admission (i.e. Approve, indicating that the defect is allowed to be released with the version to be released), temporary non-repair (i.e. Later, indicating that the version to be released will not be repaired temporarily) and no repair (i.e. Won't Fix, indicating that the version to be released will not be repaired. In this case, the management system will automatically close the defect repair on the branch corresponding to the version).

[0088] Optionally, the access permission information of the initial defect in the version to be released can be determined based on the following method: after determining multiple initial defects in the version to be released, the multiple initial defects can be displayed to the defect reviewer, and the defect reviewer enters the access permission information of each initial defect in the version to be released; or the defect reviewer obtains multiple defects to be managed in the management system, and for each defect to be managed, the defect reviewer enters the access permission information of the defect to be managed on its multiple versions. The present disclosed embodiment is not limited to this.

[0089] In the embodiment of the present disclosure, by obtaining multiple initial defects related to the version to be released, and based on the access permission information of each initial defect in the version to be released and the defect repair status on the version to be released, the association relationship between the defect and the version, as well as the defect repair status of the defect on the version are utilized, and multiple defects to be repaired in the version to be released are automatically screened out to facilitate the subsequent advancement of the repair progress of the defects to be repaired, thereby improving the efficiency of version release.

[0090] As an optional embodiment, the method further includes: In response to the to-be-released version creation event, create the to-be-released version and the release branch corresponding to the to-be-released version, and set the version status of the to-be-released version to the active status; Publish the release branch corresponding to the version to be released, and then include: Update the version status of the version to be released from active to released.

[0091] Specifically, when a new version needs to be released, the publisher can trigger a to-be-released version creation event on the management system. The management system can respond to the to-be-released version creation event, create the to-be-released version, and automatically create a release branch (i.e., Branch) corresponding to the to-be-released version. The release branch can be a branch used to prepare for the release version, and at the same time, set the version status of the to-be-released version to the active state.

[0092] When the management system meets the release conditions corresponding to the version to be released and releases the release branch corresponding to the version to be released, the version status of the version to be released can be updated from the active status to the released status.

[0093] In the embodiments of the present disclosure, by automatically creating a release branch corresponding to the version to be released when creating the version to be released, there is no need for R&D personnel to manually create the corresponding release branch, which further reduces manual operation costs and improves efficiency. By setting the version status corresponding to the version, the release status of each version is tracked based on the version status corresponding to the version, which is conducive to the management of multiple versions.

[0094] Figure 4 A schematic diagram of an entity state update provided by an embodiment of the present disclosure, such as Figure 4 As shown, the process of automatically updating the version status of the version to be released in the management system and the defect repair status of the defect to be repaired in the version to be released includes: 1. In response to the version creation event of the publisher, when the management system creates the version to be released, the version status of the version to be released enters the active state, and the management system automatically creates the corresponding release branch; 2. The R&D personnel create an original defect entity for the version to be released in the associated system (i.e., the defect newly added in the version to be released). The associated system sends the defect creation event to the management system. The management system receives the defect creation event, creates a corresponding defect concept entity as the defect to be fixed in the version to be released, obtains the associated version information of the defect to be fixed, and sets the defect repair status of the defect to be fixed in the version to be released to the status to be fixed; 3. The R&D personnel can create a trunk repair for the original defect entity corresponding to the defect to be repaired in the associated system. After the trunk repair is completed, the associated system will send a trunk repair event for the defect to be repaired to the management system. Based on the trunk repair event received, the management system determines that the trunk of the defect to be repaired in the version to be released has been repaired, and updates the defect repair status of the defect to be repaired in the version to be released from the state to be repaired to the state of the trunk repaired; 4. Based on at least one associated version corresponding to the defect to be fixed, the management system can automatically create branch fixes for the release branches corresponding to each associated version. A target associated version can be selected from multiple associated versions, and the target associated version includes the version to be released; the trunk fix of the defect to be fixed in the version to be released can be merged into the release branch of the defect to be fixed in the version to be released, completing the branch fix of the defect to be fixed on the release branch of the version to be released, and updating the defect repair status of the defect to be fixed on the version to be released from the trunk fixed status to the to-be-released status; 5. When the management system detects that the release conditions corresponding to the version to be released are met, it will release the release branch of the version to be released, release the defect to be fixed along with the release branch, and update the defect repair status of the defect to be fixed on the version to be released from the to-be-released state to the fixed state.

[0095] At this point, in the process of a version release operation, the status update of the version to be released and the defects to be fixed is completed.

[0096] Figure 5 A schematic diagram of a release process provided by an embodiment of the present disclosure, such as Figure 5 As shown in the figure, the release process specifically includes: 1. The publisher creates a version on the system: After determining the version to be released and carrying out the release process, the publisher creates the corresponding version on the management system, and the management system automatically creates the corresponding release branch based on the version; 2. R&D personnel mark the associated versions of the defect: R&D personnel mark the defect with "affects-{version number}"; 3. The defect auditor marks the access permission information of the defect: The defect auditor marks the access permission information of the defect in the version to be released on the defect; 4. The management system automatically creates a branch repair for the release branch: When the system determines that the defect reviewer has marked the defect as approved (Approve), and the repair has been completed on the trunk, the management system will automatically create a branch repair on the corresponding release branch based on the repair of the trunk. After the creation is completed, the management system will determine whether it can be automatically merged into the release branch, and if so, it will automatically merge into the release branch.

[0097] 5. Defects that have been repaired on the release branch will be released along with the version: When the version publisher decides to release the version, the management system will push the corresponding release branch into the release process, and the defect fixes that have been repaired on the release branch will be released along with the release branch.

[0098] The release process management may involve multiple roles, including release personnel, R&D personnel, and defect reviewers, and each role has different responsibilities. The management system ensures the accuracy of the entity status and establishes the status connection between entities. Different personnel only need to focus on the business logic (the version affected by the defect, the association between the repair and the defect, and the trunk repair of the defect). The management system automatically adjusts the entity status changes involved, eliminates unnecessary communication and dependence between different personnel, and improves the efficiency and convenience of collaboration among different personnel.

[0099] In addition, the management system can also provide different views for relevant personnel to view and operate based on the relationship between entities.

[0100] Figure 6 A schematic diagram of a version view provided in an embodiment of the present disclosure, such as Figure 6 As shown, for a specified release version, the management system automatically aggregates and displays all defects that are marked as affecting the release version.

[0101] Figure 7 A schematic diagram of a defect view provided by an embodiment of the present disclosure, such as Figure 7 As shown, for a specified defect, the management system automatically displays the repair status of the defect in all affected release versions.

[0102] As an optional embodiment, the management system may include a data storage module, a user interface module, an event receiving module, a state change module and an entity operation module.

[0103] The data storage module needs to maintain system entity data, including defect information, version information, PR information, and the relationship between entities. When the system receives a new entity event or responds through the user interface module, it needs to update the data through the data storage module.

[0104] The user interface module provides a web graphical interface that allows users to access various functions of the system through a browser. The pages include version management page, defect management page, and defect detail page. When a user accesses the system through a browser, the page obtains entity data provided by the backend service through HTTP requests and renders it dynamically. The user's request for entity status change will be passed to the status change module for processing. After the operation, the data display of the relevant page will be automatically updated to ensure real-time synchronization of the interface and data.

[0105] The event receiving module is used to receive entity operation events and record them in the system, such as defects in the associated system (taking Github as an example), PR additions, and other operations. After being processed by the state change module, the event entity information is saved in the data storage module. The event receiving module has an event monitoring mechanism, which can receive event requests when operations occur in the associated system. To receive events from the associated system, you need to configure the HTTP address for receiving events for this system on the associated system.

[0106] The state change module is responsible for tracking the state changes of each entity in the system and ensuring the correctness and consistency of the state changes. Whenever an event is triggered, the module will make state changes to the relevant entities and use the data storage module to store them. At the same time, if the relevant state change causes the state changes of other entities, the state change module will request the entity operation module to make changes to the entities of the related system.

[0107] The entity operation module implements the specific operation logic of the associated system. When the state of the entity in this system changes, it needs to be reflected in the associated system through the entity operation module to ensure that the entity state of the associated system is consistent with that of this system.

[0108] Figure 8 A schematic diagram of a process of creating a version provided in an embodiment of the present disclosure, such as Figure 8 As shown, the administrator adds version VersionX (i.e., the version to be released) through the version management page of the user interface module, and synchronously creates version VersionX' in the associated system through the entity operation module. After the event receiving module receives the notification of successful version creation in the associated system, it calls the data storage module to store the version information; the state change module creates a corresponding version release branch BranchX for version VersionX, and synchronously creates a release branch BranchX' in the associated system through the entity operation module, and calls the data storage module to store the branch information.

[0109] Fig. 9 A schematic diagram of a process of creating a defect provided by an embodiment of the present disclosure is shown in FIG. Fig. 9 As shown, the R&D personnel create a defect IssueX on the associated system (Github), and the associated system sends a defect creation event to the management system. The management system receives the event through the event receiving module, calls the state change module to synchronously create the corresponding defect IssueX' in the management system, and stores the defect information through the data storage module.

[0110] R&D personnel mark the defect with an "affect-version identifier" (affect-versionX), and the associated system sends an event to the management system. The management system receives the corresponding event through the event receiving module and stores the associated information between the defect and the version through the data storage module. Users can query the relevant information of the version and defect in the defect management view and defect detail view of the user interface module.

[0111] Fig.10 A schematic diagram of a trunk repair process provided by an embodiment of the present disclosure, such as Fig.10 As shown, the R&D personnel creates a repair PullRequestX (i.e., trunk repair) on the associated system, and the associated system sends a repair creation event to the management system. The management system receives the event through the event receiving module, calls the state change module to synchronously create PullRequestX' in the management system, and calls the data storage module to store the repair information; the R&D personnel also identify the associated defect IssueX in the description of PullRequestX, and the associated text is "Issue Number: IssueX". The repair description information is passed to the management system through the event receiving module, and the management system stores the associated information of the defect and the repair through the data storage module. Users can query the relevant information of the defect and the repair in the defect detail view of the user interface module.

[0112] Fig.11 A schematic diagram of a branch repair process provided by an embodiment of the present disclosure is shown in FIG. Fig.11 As shown, the R&D personnel complete the repair of PullRequestX and close the defect IssueX on the associated system. The management system receives the repair event of PullRequestX and the closing event of defect IssueX through the event receiving module, and passes it to the state change module. The state change module determines that the repair has been completed on the trunk branch, and calls the data storage module to store the trunk repair information, obtains the association information of defect IssueX and version VersionX through the data storage module, calls the entity operation module to create a branch repair PullRequestY on BranchX based on the repair of PullRequestX, and synchronously creates a branch repair on the associated system through the entity operation module.

[0113] The R&D personnel complete the merge operation of the branch repair PullRequestY on the associated system. The management system receives the corresponding event through the event receiving module, sets the defect repair status of the defect IssueX on version VersionX to the pending release status through the status change module, and calls the data storage module to store the version repair information.

[0114] Fig.12A schematic diagram of a version release process provided by an embodiment of the present disclosure, such as Fig.12 As shown, the administrator sets the version status of VersionX to the released status through the user interface module, and the management system sets the status of all defects (including defect IssueX) that have been repaired on VersionX to the fixed status through the status change module, and calls the data storage module to store the version release information. The status change module sets the status of the repaired defect to the released status, and calls the data storage module to store the released defect information. The status change module integrates the unrepaired defects into the next version, and calls the storage module to store the unrepaired defect information.

[0115] The management system provided by the embodiments of the present disclosure is a defect-centric multi-version management system. "Defect-centric" can be understood as associating versions and repairs through defects, making repair decisions for defects, and tracking the repair status on multiple versions through defects. Among them, the association between defects and versions can be established by R&D personnel marking "impact version identifier" on the defects; the association between defects and repairs can be associated by R&D personnel marking "associated defects" on the repairs. Repairs include trunk repairs and release branch repairs. Trunk repairs are not directly associated with versions. Release branch repairs are trunk repairs performed on the corresponding version branch based on the "impact version identifier" of the associated defect.

[0116] By automatically establishing and maintaining the relationships between defects, versions, and fixes; based on these relationships, automatic transfer and update of entity status are achieved; and multi-dimensional views based on the relationships are provided, such as version views and defect views.

[0117] The management system provided by the embodiment of the present disclosure supports the rapid inheritance, management and release status management of the same defect by multiple versions. In addition, the release status of the same defect in different versions is automatically judged by the management system through the completion status of the associated repair, thereby maintaining the release status of different versions under a defect as the center, and realizing that the multi-version list of its output can be queried from a defect perspective, reducing a large number of manual operations on defects.

[0118] Fig.13 A schematic diagram of the structure of a version management device provided by an embodiment of the present disclosure is shown in FIG. Fig. 9 As shown, the device of this embodiment may include: The determination module 210 is used to determine a version to be released and a plurality of defects to be fixed in the version to be released, wherein the defect repair status of the defect to be fixed on the version to be released is a to-be-repaired status; The status update module 220 is used to update the defect repair status of each defect to be repaired on the version to be released from the state to be repaired to the state to be released if the repair of the defect to be repaired on the release branch of the version to be released has been completed; A first defect determination module 230 is configured to update a defect to be repaired whose defect repair status is updated to a to-be-released status among the multiple defects to be repaired as a first defect; The version release module 240 is used to release the release branch corresponding to the version to be released if the release conditions corresponding to the version to be released are met, release each first defect along with the release branch, and update the defect repair status of each first defect in the version to be released from the to-be-released state to the fixed state.

[0119] As an optional embodiment, the management system is used to manage the associated system; The status update module is specifically used to update the defect repair status of the defect to be repaired on the version to be released from the to-be-repaired state to the to-be-released state when the repair of the release branch of the defect to be repaired on the version to be released is completed: If it is determined based on the trunk repair event for the defect to be repaired that the defect to be repaired has been repaired on the trunk, then the defect repair status of the defect to be repaired on the version to be released is updated from the to-be-repaired status to the trunk repaired status; The trunk repair event of the defect to be repaired is triggered when the associated system receives a trunk repair for the original defect entity corresponding to the defect to be repaired; the trunk repair event includes information about the defect to be repaired; Based on at least one associated version corresponding to the defect to be fixed, create a branch repair of a release branch corresponding to each associated version; Determine a target associated version from each associated version; the target associated version includes the version to be released; For each target associated version, based on the branch repair of the release branch of the target associated version, the release branch of the target associated version is repaired, and the defect repair status of the defect to be repaired on the target associated version is updated from the trunk repaired status to the to-be-released status.

[0120] As an optional implementation example, the device also includes: A first association relationship establishing module, configured to take defects other than the first defect among the multiple defects to be fixed in the to-be-released version as second defects; After the next version corresponding to the to-be-released version is created, the next version is used as the associated version corresponding to each second defect, and the defect repair status of each second defect on the next version is set to a to-be-repaired status; The next version corresponding to the version to be released is a version obtained by updating the version to be released.

[0121] As an optional embodiment, the device further includes: A second association relationship establishing module is configured to determine a third defect newly added in the to-be-released version based on the defect creation event if a defect creation event for the to-be-released version sent by the association system is received; For each third defect, at least one associated version corresponding to the third defect is obtained, and a defect repair state of the third defect on each corresponding associated version is set to a to-be-repaired state; the at least one associated version includes the to-be-released version.

[0122] As an optional embodiment, when the status update module determines that the defect to be repaired has been repaired on the trunk based on the trunk repair event for the defect to be repaired, it is specifically configured to: In response to a defect closing event for the defect to be fixed, determining that the defect to be fixed has been fixed on the trunk of the version to be released; The defect closing event for the defect to be repaired is triggered after each trunk repair event corresponding to the defect to be repaired.

[0123] As an optional embodiment, the device further includes a defect determination module to be repaired, which is used to: Obtaining a plurality of initial defects related to the version to be released; For each initial defect, if the admission permission information of the initial defect on the version to be released is admission, and the defect repair status of the initial defect on the version to be released is pending repair, the initial defect is used as the pending repair defect of the version to be released.

[0124] As an optional embodiment, the device further includes a version creation module, which is used to: In response to the to-be-released version creation event, create the to-be-released version and the release branch corresponding to the to-be-released version, and set the version status of the to-be-released version to the active status; The version status update module is used to update the version status of the to-be-released version from an active status to a released status.

[0125] As an optional embodiment, the association system includes multiple original defect entities, multiple original repair entities and multiple original version entities; the multiple defects to be managed in the management system include multiple defect concept entities corresponding to the multiple original defect entities respectively; the multiple repairs to be managed in the management system include multiple repair concept entities corresponding to the multiple original repair entities respectively; the multiple versions to be managed in the management system include multiple version concept entities corresponding to the multiple original version entities respectively; The status updates of the entities in the association system and the conceptual entities to which the entities correspond in the management system are synchronized.

[0126] The device of the embodiment of the present disclosure can execute the method provided by the embodiment of the present disclosure, and its implementation principle is similar and has corresponding technical effects. The actions performed by each module in the device of each embodiment of the present disclosure correspond to the steps in the method of each embodiment of the present disclosure. For the detailed functional description of each module of the device, please refer to the description in the corresponding method shown in the previous text, which will not be repeated here.

[0127] In the embodiments of the present disclosure, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories), or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0128] In an embodiment of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, and the processor executes the above-mentioned computer program to implement the steps of the method provided by any optional embodiment of the present disclosure. Compared with the prior art, it can be achieved that: for each defect to be repaired in the version to be released, by setting the defect repair status of the defect to be repaired on the version to be released, and automatically updating the defect repair status of the defect to be repaired on the version to be released in real time, the defect repair status of each defect on each version is tracked. In particular, for the scenario of multi-version management, when the number of versions increases, the number of defects to be managed will also increase significantly. Compared with the existing version management tools that require R&D personnel to manually update and align the repair progress of each defect on each version, the version management method provided in the embodiment of the present disclosure does not require R&D personnel to manually update and align the defect repair status of each defect on each version, saving a lot of manpower costs and time, and improving the efficiency of version management. Furthermore, the first defect that has been repaired is automatically determined according to the defect repair status of each defect to be repaired in the version to be released, and the first defect is released along with the release branch, thereby realizing the automatic release of the version to be released and improving the efficiency of version release; at the same time, it avoids the impact of operational errors or omissions of R&D personnel on the version quality and ensures the quality of the released version.

[0129] In an alternative embodiment, an electronic device is provided, such as Fig.14 As shown, Fig.14 The electronic device 4000 shown includes: a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, such as through a bus 4002. Optionally, the electronic device 4000 may also include a transceiver 4004, which may be used for data interaction between the electronic device and other electronic devices, such as data transmission and / or data reception. It should be noted that in actual applications, the transceiver 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present disclosure.

[0130] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of the present invention. Processor 4001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0131] The bus 4002 may include a path to transmit information between the above components. The bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 4002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.14 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0132] The memory 4003 may be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store computer programs and can be read by a computer, without limitation herein.

[0133] The memory 4003 is used to store the computer program for executing the embodiment of the present disclosure, and the execution is controlled by the processor 4001. The processor 4001 is used to execute the computer program stored in the memory 4003 to implement the steps shown in the above method embodiment.

[0134] Among them, electronic devices include but are not limited to: mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), wearable devices, etc., and fixed terminals such as digital TVs, desktop computers, etc.

[0135] An embodiment of the present disclosure provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps and corresponding contents of the aforementioned method embodiment can be implemented.

[0136] The embodiments of the present disclosure also provide a computer program product, including a computer program, which can implement the steps and corresponding contents of the aforementioned method embodiments when executed by a processor.

[0137] It should be understood that, although the flowchart of the embodiment of the present disclosure indicates each operation step by arrows, the implementation order of these steps is not limited to the order indicated by the arrows. Unless clearly stated herein, in some implementation scenarios of the embodiment of the present disclosure, the implementation steps in each flowchart can be executed in other orders according to demand. In addition, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage in these sub-steps or stages can also be executed at different times. In scenarios with different execution times, the execution order of these sub-steps or stages can be flexibly configured according to demand, and the embodiment of the present disclosure does not limit this.

[0138] The above is only an optional implementation method for some implementation scenarios of the present disclosure. It should be pointed out that for ordinary technicians in this technical field, without departing from the technical concept of the scheme of the present disclosure, other similar implementation methods based on the technical ideas of the present disclosure are also within the protection scope of the embodiments of the present disclosure.

Claims

1. A version management method, characterized in that: Applied to management systems, including: Determine a version to be released, and a plurality of defects to be fixed in the version to be released, wherein the defect fixing status of the defects to be fixed on the version to be released is a to-be-fixed status; For each defect to be fixed, if the repair of the defect to be fixed in the release branch of the version to be released has been completed, update the defect repair status of the defect to be fixed in the version to be released from the state to be fixed to the state to be released; updating a defect to be fixed whose defect repair status is to be released among the multiple defects to be fixed as a first defect; If the release conditions corresponding to the version to be released are met, the release branch corresponding to the version to be released is released, each first defect is released along with the release branch, and each first defect is updated in the defect repair status of the version to be released from the to-be-released state to the fixed state.

2. The method according to claim 1, characterized in that The management system is used to manage the associated system; If the repair of the release branch of the to-be-repaired defect on the to-be-released version has been completed, updating the defect repair status of the to-be-repaired defect on the to-be-released version from a to-be-repaired status to a to-be-released status, comprises: If it is determined based on the trunk repair event for the defect to be repaired that the defect to be repaired has been repaired on the trunk, then the defect repair status of the defect to be repaired on the version to be released is updated from the to-be-repaired status to the trunk repaired status; The trunk repair event of the defect to be repaired is triggered when the associated system receives a trunk repair for the original defect entity corresponding to the defect to be repaired; the trunk repair event includes information about the defect to be repaired; Based on at least one associated version corresponding to the defect to be fixed, create a branch repair of a release branch corresponding to each associated version; Determine a target associated version from each associated version; the target associated version includes the version to be released; For each target associated version, based on the branch repair of the release branch of the target associated version, the release branch of the target associated version is repaired, and the defect repair status of the defect to be repaired on the target associated version is updated from the trunk repaired status to the to-be-released status.

3. The method according to claim 1, characterized in that The method further comprises: taking defects other than the first defect among the multiple defects to be fixed in the to-be-released version as second defects; After the next version corresponding to the to-be-released version is created, the next version is used as the associated version corresponding to each second defect, and the defect repair status of each second defect on the next version is set to a to-be-repaired status; The next version corresponding to the version to be released is a version obtained by updating the version to be released.

4. The method according to claim 1, characterized in that The method further comprises: If a defect creation event for the version to be released sent by the associated system is received, determining a third defect newly added in the version to be released based on the defect creation event; For each third defect, at least one associated version corresponding to the third defect is obtained, and a defect repair state of the third defect on each corresponding associated version is set to a to-be-repaired state; the at least one associated version includes the to-be-released version.

5. The method according to claim 2, characterized in that: The determining that the defect to be repaired has been repaired on the trunk based on the trunk repair event for the defect to be repaired includes: In response to a defect closing event for the defect to be fixed, determining that the defect to be fixed has been fixed on the trunk of the version to be released; The defect closing event for the defect to be repaired is triggered after each trunk repair event corresponding to the defect to be repaired.

6. The method according to claim 1, characterized in that The multiple defects to be fixed in the version to be released are determined based on the following method: Obtaining a plurality of initial defects related to the version to be released; For each initial defect, if the admission permission information of the initial defect on the version to be released is admission, and the defect repair status of the initial defect on the version to be released is pending repair, the initial defect is used as the pending repair defect of the version to be released.

7. The method according to claim 1, characterized in that The method further comprises: In response to the to-be-released version creation event, create the to-be-released version and the release branch corresponding to the to-be-released version, and set the version status of the to-be-released version to the active status; The step of releasing the release branch corresponding to the to-be-released version further includes: The version status of the to-be-released version is updated from the active status to the released status.

8. According to the method of claim 2, the association system includes multiple original defect entities, multiple original repair entities and multiple original version entities; the multiple defects to be managed in the management system include multiple defect concept entities corresponding to the multiple original defect entities; the multiple repairs to be managed in the management system include multiple repair concept entities corresponding to the multiple original repair entities; the multiple versions to be managed in the management system include multiple version concept entities corresponding to the multiple original version entities; The status updates of the entities in the association system and the conceptual entities to which the entities correspond in the management system are synchronized.

9. A version management device, characterized in that: include: A determination module, used to determine a version to be released, and a plurality of defects to be fixed in the version to be released, wherein the defect repair status of the defect to be fixed on the version to be released is a to-be-fixed status; A status update module is used to update the defect repair status of each defect to be repaired on the version to be released from a to-be-repaired state to a to-be-released state if the repair of the defect to be repaired on the release branch of the version to be released has been completed; A first defect determination module, configured to update a defect to be repaired whose defect repair status is updated to a to-be-released status among the multiple defects to be repaired as a first defect; The version release module is used to release the release branch corresponding to the version to be released if the release conditions corresponding to the version to be released are met, release each first defect along with the release branch, and update the defect repair status of each first defect in the version to be released from the to-be-released state to the fixed state.

10. An electronic device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 8.

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

12. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images