Version Management Method, Device, Electronic Device, and Storage Medium

Abstract

Embodiments of the present disclosure provide a version management method, apparatus, electronic device, and storage medium, which relate to the field of database technologies, such as the field of distributed databases. The method includes: determining a version to be released and multiple defects to be repaired corresponding thereto; for each defect to be repaired, if the repair on the release branch of the defect to be repaired in the version to be released is completed, updating the defect repair status of the defect to be repaired in the version to be released from the to-be-repaired status to the to-be-released status; regarding the defects to be repaired whose defect repair status is updated to the to-be-released status among the multiple defects to be repaired as first defects; if the release conditions corresponding to the version to be released are met, releasing the release branch corresponding to the version to be released, releasing each first defect along with the release branch, and updating the defect repair status of each first defect in the version to be released from the to-be-released status to the repaired status. Embodiments of the present disclosure improve the efficiency of version management.

Description

Technical Field

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

[0002] With the expansion of the scale, increase in complexity, and increase in iteration frequency of software projects, the version management of software has become particularly crucial. Currently, 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 issue tracking tool) and GitHub Issues (a function in Github for tracking and managing software projects) are widely used solutions in the industry.

[0003] Existing version management tools can achieve simple single-version management. However, when the number of versions increases, a large amount of manual operation by R & D personnel is required to repeatedly copy and associate defects, consuming a large amount of manpower and time and having low efficiency. Summary of the Invention

[0004] Embodiments of the present disclosure provide a version management method, apparatus, 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:

[0005] According to one aspect of the embodiments of the present disclosure, there is provided a version management method applied to a management system. The method includes:

[0006] Determine a version to be released and multiple defects to be repaired in the version to be released, where the defect repair status of the defects to be repaired in the version to be released is a to-be-repaired status;

[0007] For each defect to be repaired, if the repair on the release branch of the defect to be repaired in the version to be released is completed, update the defect repair status of the defect to be repaired in the version to be released from the to-be-repaired status to a to-be-released status;

[0008] Use the defects to be repaired whose defect repair status is updated to the to-be-released status among the multiple defects to be repaired as first defects;

[0009] If the release conditions corresponding to the version to be released are met, release the release branch corresponding to the version to be released, 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 status to a repaired status.

[0010] Optionally, the management system is used to manage an associated system;

[0011] If the repair of the defect to be repaired on the release branch of the version to be released is completed, updating the defect repair status of the defect to be repaired on the version to be released from the to-be-repaired status to the to-be-released status includes:

[0012] If it is determined that the defect to be repaired has been repaired on the main trunk based on the main trunk repair event for the defect to be repaired, updating the defect repair status of the defect to be repaired on the version to be released from the to-be-repaired status to the main-trunk-repaired status;

[0013] The main trunk repair event of the defect to be repaired is triggered when the associated system receives the main trunk repair for the original defect entity corresponding to the defect to be repaired; the main trunk repair event includes information about the defect to be repaired;

[0014] Based on at least one associated version corresponding to the defect to be repaired, creating branch repairs for the release branches respectively corresponding to each associated version;

[0015] Determining a target associated version from each associated version; the target associated version includes the version to be released;

[0016] For each target associated version, based on the branch repair of the release branch of the target associated version, repairing the release branch of the target associated version, and updating the defect repair status of the defect to be repaired on the target associated version from the main-trunk-repaired status to the to-be-released status.

[0017] Optionally, the method further includes:

[0018] Regarding the defects other than the first defect among the multiple defects to be repaired of the version to be released as second defects;

[0019] After the creation of the next version corresponding to the version to be released, taking the next version as the associated version corresponding to each second defect, and setting the defect repair status of each second defect on the next version to the to-be-repaired status;

[0020] Wherein, the next version corresponding to the version to be released is the version obtained by updating based on the version to be released.

[0021] Optionally, the method further includes:

[0022] If a defect creation event for the version to be released sent by the associated system is received, determining the newly added third defect in the version to be released based on the defect creation event;

[0023] For each third defect, obtain at least one associated version corresponding to the third defect, and set the defect repair status of the third defect on each corresponding associated version to the to-be-repaired status; the at least one associated version includes the to-be-released version.

[0024] 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:

[0025] In response to a defect closing event for the defect to be repaired, it is determined that the defect to be repaired has been repaired on the trunk of the to-be-released version;

[0026] The defect closing event for the defect to be repaired is triggered after each trunk repair event corresponding to the defect to be repaired.

[0027] Optionally, the multiple defects to be repaired in the to-be-released version are determined based on the following method:

[0028] Obtain multiple initial defects related to the to-be-released version;

[0029] For each initial defect, if the admission permission information of the initial defect on the to-be-released version is admission and the defect repair status of the initial defect on the to-be-released version is the to-be-repaired status, then use the initial defect as a defect to be repaired in the to-be-released version.

[0030] Optionally, the method further includes:

[0031] In response to a to-be-released version creation event, create a to-be-released version, as well as a release branch corresponding to the to-be-released version, and set the version status of the to-be-released version to the active status;

[0032] After publishing the release branch corresponding to the to-be-released version, it further includes:

[0033] Update the version status of the to-be-released version from the active status to the released status.

[0034] Optionally, 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 respectively corresponding to the multiple original defect entities; the multiple repairs to be managed in the management system include multiple repair concept entities respectively corresponding to the multiple original repair entities; the multiple versions to be managed in the management system include multiple version concept entities respectively corresponding to the multiple original version entities;

[0035] The status updates of each entity in the associated system and each concept entity respectively corresponding to each entity in the management system are synchronized.

[0036] According to another aspect of the embodiments of the present disclosure, a version management device is provided. The device includes:

[0037] A determination module, configured to determine a version to be released and multiple defects to be repaired in the version to be released, where the defect repair status of the defects to be repaired in the version to be released is the to-be-repaired status;

[0038] A status update module, configured to, for each defect to be repaired, if the repair on the release branch of the defect to be repaired in the version to be released is completed, update the defect repair status of the defect to be repaired in the version to be released from the to-be-repaired status to the to-be-released status;

[0039] A first defect determination module, configured to use the defects to be repaired whose defect repair status is updated to the to-be-released status among the multiple defects to be repaired as the first defects;

[0040] A version release module, configured to, if the release conditions corresponding to the version to be released are met, release the release branch corresponding to the version to be released, 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 status to the repaired status.

[0041] According to another aspect of the embodiments of the present disclosure, an electronic device is provided. The electronic device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of any of the above version management methods are implemented.

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

[0043] According to one aspect of the embodiments of the present disclosure, a computer program product is provided. The computer program product includes a computer program. When the computer program is executed by a processor, the steps of any of the above version management methods are implemented.

[0044] The beneficial effects brought by the technical solutions provided by the embodiments of the present disclosure are:

[0045] For each defect to be fixed in the version to be released, by setting the defect repair status of the defect to be fixed in the version to be released and automatically updating the defect repair status of the defect to be fixed in the version to be released in real time, the tracking of the defect repair situation of each defect in each version is realized. 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 developers to manually update and align the repair progress of each defect in each version, the version management method provided by the embodiments of the present disclosure does not require developers to manually update and align the defect repair situation of each defect in each version, saving a large amount of labor costs and time and improving the efficiency of version management.

[0046] Further, the first defects that have been repaired are automatically determined according to the defect repair status of each defect to be fixed in the version to be released, and the first defects are 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 developers' operation mistakes or omissions on the version quality and ensures the quality of the released version. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, the following will briefly introduce the drawings required for description in the embodiments of the present disclosure.

[0048] Figure 1 It is a schematic diagram of the application scenario of the version management method provided by the embodiments of the present disclosure;

[0049] Figure 2 It is a schematic diagram of the entity status synchronization between systems provided by the embodiments of the present disclosure;

[0050] Figure 3 It is a schematic diagram of the process of the version management method provided by the embodiments of the present disclosure;

[0051] Figure 4 It is a schematic diagram of the entity status update provided by the embodiments of the present disclosure;

[0052] Figure 5 It is a schematic diagram of the release process provided by the embodiments of the present disclosure;

[0053] Figure 6 It is a schematic diagram of the version view provided by the embodiments of the present disclosure;

[0054] Figure 7 It is a schematic diagram of the defect view provided by the embodiments of the present disclosure;

[0055] Figure 8 It is a schematic diagram of the process of creating a version provided by the embodiments of the present disclosure;

[0056] Figure 9 A flowchart of a process for creating defects provided by an embodiment of the present disclosure;

[0057] Figure 10 A flowchart of a process for trunk repair provided by an embodiment of the present disclosure;

[0058] Figure 11 A flowchart of a process for branch repair provided by an embodiment of the present disclosure;

[0059] Figure 12 A flowchart of a process for version release provided by an embodiment of the present disclosure;

[0060] Figure 13 A schematic structural diagram of a version management device provided by an embodiment of the present disclosure;

[0061] Figure 14 A schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. Detailed implementation manners

[0062] The embodiments of the present disclosure will be described below with reference to the accompanying drawings in the present disclosure. It should be understood that the embodiments described below in conjunction with the accompanying 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.

[0063] Those skilled in the art of the present technology can understand that unless specifically stated otherwise, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the terms "including" and "comprising" used in the embodiments of the present disclosure mean 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 of other features, information, data, steps, operations, elements, components and / or their combinations supported by the art of the present technology, etc. It should be understood that when we say an element is "connected" or "coupled" to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used herein can include a wireless connection or a 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 implementation as "A", or implementation as "B", or implementation as "A and B".

[0064] To make the purpose, technical solutions and advantages of the present disclosure clearer, the embodiments of the present disclosure will be further described in detail below with reference to the accompanying drawings.

[0065] 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. At the core of these frameworks is the ability to continuously and automatically perform software builds, tests, and releases 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 issue tracking tool), GitHub Issues (a feature in Github for tracking and managing software projects), etc., 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.

[0066] In large-scale locally deployed software projects, especially database systems like TiDB (a distributed database), version management becomes particularly critical. TiDB is a rapidly iterating database software, usually released at a pace of five to six major versions per year. Each released major version has a three-year lifecycle. As TiDB continues to be developed and iterated, new functionality, performance, and security defects are continuously discovered, and these issues may also exist in the released major versions and affect users' actual use. Therefore, it is necessary to continuously merge necessary fixes into the major versions still in the lifecycle in the form of patches and release patch versions as needed.

[0067] 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 can be applied to all affected versions in a timely and accurate manner.

[0068] Systems such as GitHub Issues and JIRA provide functions for defect tracking and task management, enabling teams to record problems, discuss solutions, and track the progress of fixes. These tools usually require developers and project managers to spend a lot of time on manual operations and data synchronization. Especially in scenarios involving multiple software versions, this manual process is often complex and error-prone.

[0069] Existing version management methods have the following problems:

[0070] Difficult version defect management: There are usually a large number of main versions during the life cycle. R & D personnel need to spend a huge amount of energy and time to sort out the repair status of all defects affecting the versions, analyze and process them one by one to ensure the timely release of the versions. If there is a slight oversight, defects may be missed, thus affecting the version quality.

[0071] Difficult defect repair judgment: One 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.

[0072] Difficult personnel collaboration: One defect requires different personnel to pay attention at different stages. Since it is difficult to judge the stage of defect repair, it is very difficult for each responsible person to know when they should intervene in the handling of which defects.

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

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

[0075] Figure 1 It is a schematic diagram of the application scenario of the version management method provided by the embodiments of the present disclosure. As Figure 1 shown, the application scenario includes a management system and an associated system. Among them, the management system is used to manage the associated system, and the associated system can be any version control system with the concepts of defect, repair, and branch entities, such as Gitlab and Github.

[0076] The associated system includes multiple original defect entities, multiple original repair entities and multiple original version entities; multiple defects to be managed in the management system include multiple defect concept entities corresponding to the multiple original defect entities respectively; multiple repairs to be managed in the management system include multiple repair concept entities corresponding to the multiple original repair entities respectively; multiple versions to be managed in the management system include multiple version concept entities corresponding to the multiple original version entities respectively;

[0077] The status updates of each original entity in the associated system and each concept entity respectively corresponding to each original entity in the management system are synchronized.

[0078] Specifically, the association system can be an existing version management system, such as Github (a hosting platform for software projects). The association system can include multiple original defect entities (i.e., issues), multiple original fix entities (i.e., Pull Requests), and multiple original version entities (i.e., versions). Among them, a "defect" usually refers to an error or problem in software, a "fix" is a direct response to these problems, and a "version" includes a series of specific function enhancements and defect fixes.

[0079] The management system is used to manage the association system. For each entity in the association system, there is a corresponding conceptual entity in the management system, and a conceptual entity refers to an entity of a conceptual type. For multiple original defect entities in the association 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 fix entities in the association system, the management system includes multiple fix conceptual entities corresponding to each original fix entity, that is, multiple fixes to be managed. For multiple original version entities in the association system, the management system includes multiple version conceptual entities corresponding to each original version entity, that is, multiple versions to be managed.

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

[0081] Figure 2 This is a schematic diagram of entity status synchronization between systems provided by an embodiment of the present disclosure. As Figure 2 shown, the entity status synchronization process between systems includes:

[0082] When a developer directly operates on an original entity in the association system (such as creating a fix or closing a defect), the status of the original entity will change. The association system will send the entity change event to the management system interface through a request. The management system receives the event, processes the status of the conceptual entity corresponding to the original entity in the management system, and stores the latest status. At the same time, if other related entities have an indirect status change due to this event, the management system will synchronously update the status change to the original entity corresponding to the related entity in the association system.

[0083] When a developer operates on a conceptual entity in the management system and this operation affects the entity status, the management system updates and stores the status of the conceptual entity targeted by this operation, and at the same time synchronously updates the status of the original entity corresponding to this conceptual entity in the association system.

[0084] By means of the two-way response between entities with corresponding relationships in the management system and the associated system, the state consistency between entities with corresponding relationships in the two systems is ensured.

[0085] Figure 3 The flowchart of a version management method provided by an embodiment of the present disclosure is shown. This method is applied to a management system, such as Figure 3 shown, and the method includes:

[0086] Step S110, determine the version to be released and multiple defects to be repaired in the version to be released. The defect repair status of each defect to be repaired in the version to be released is the to-be-repaired status.

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

[0088] The version to be released may be a version that needs to be released in the management system. The multiple defects to be repaired in the version to be released may be multiple unrepaired defects related to the version to be released. The defect repair status of each defect to be repaired in the version to be released is the to-be-repaired status. The number of versions to be released may be one or more. When the number of versions to be released is multiple, the method provided by an embodiment of the present disclosure may be executed for each version to be released.

[0089] 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 may be the same or different. The defect repair status of a defect in a certain version can be used to characterize the defect repair situation of the defect in that version.

[0090] Step S120, for each defect to be repaired, if the repair on the release branch of the defect to be repaired in the version to be released is completed, update the defect repair status of the defect to be repaired in the version to be released from the to-be-repaired status to the to-be-released status;

[0091] Step S130, use the defects to be repaired whose defect repair status is updated to the to-be-released status among the multiple defects to be repaired as the first defects.

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

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

[0094] Step S140, if the release conditions corresponding to the version to be released are met, then release the release branch corresponding to the version to be released, release each of the first defects along with the release branch, and update the defect repair status of each of the first defects in the version to be released from the to-be-released status to the fixed status.

[0095] 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 of the first defects is distributed along with the release branch, and the defect repair status of each of the first defects in the version to be released is updated from the to-be-released status to the fixed status.

[0096] Optionally, the version to be released has a corresponding preset release time. When the preset release time corresponding to the version to be released is reached, it is determined that the release conditions corresponding to the version to be released are met, where the preset release time can be a moment or a time period. It can also be that when a version release instruction from the release manager for the version to be released is received, it is determined that the release conditions corresponding to the version to be released are met; it can also combine the two. When the preset time period corresponding to the version to be released is reached and a version release instruction from the release manager for the version to be released is received, it is determined that the release conditions corresponding to the version to be released are met. The present disclosure embodiment does not make specific limitations on the release conditions.

[0097] In the embodiment of the present disclosure, for each defect to be fixed in the version to be released, by setting the defect repair status of the defect to be fixed in the version to be released and automatically updating the defect repair status of the defect to be fixed in the version to be released in real time, the tracking of the defect repair situation of each defect in each version is realized. 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 developers to manually update and align the repair progress of each defect in each version, the version management method provided by the embodiment of the present disclosure does not require developers to manually update and align the defect repair situation of each defect in each version, saving a large amount of labor costs and time and improving the efficiency of version management.

[0098] Furthermore, the first defects that have been repaired are automatically determined according to the defect repair status of each defect to be fixed in the version to be released, and the first defects are 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 developers' operation mistakes or omissions on the version quality and ensures the quality of the released version.

[0099] As an alternative embodiment, a management system is used to manage an associated system;

[0100] If the repair of a defect to be repaired on the release branch of the version to be released is completed, update the defect repair status of the defect to be repaired on the version to be released from the to-be-repaired status to the to-be-released status, including:

[0101] If it is determined that the defect to be repaired has been repaired on the main branch based on the main-branch repair event for the defect to be repaired, update the defect repair status of the defect to be repaired on the version to be released from the to-be-repaired status to the main-branch repaired status; the main-branch repair event of the defect to be repaired is triggered when the associated system receives the main-branch repair for the original defect entity corresponding to the defect to be repaired; the main-branch repair event includes the information of the defect to be repaired targeted;

[0102] Create branch repairs for the release branches respectively corresponding to each of the at least one associated version corresponding to the defect to be repaired;

[0103] Determine a target associated version from each of the associated versions; the target associated version includes the version to be released;

[0104] For each target associated version, based on the branch repair of the release branch of the target associated version, repair the release branch of the target associated version, and update the defect repair status of the defect to be repaired on the target associated version from the main-branch repaired status to the to-be-released status.

[0105] Specifically, for each defect to be repaired, there is an original defect entity corresponding to it in the associated system, and a developer can create a main-branch repair for the original defect entity in the associated system. After the main-branch repair is completed, the associated system will send a main-branch repair event for the defect to be repaired to the management system, and the main-branch repair event can include the information of the defect to be repaired targeted.

[0106] A defect can correspond to multiple repair operations. After the management system receives all the main-branch repair events corresponding to the defect to be repaired, it can determine that the defect to be repaired has been repaired on the main branch, and then update the defect repair status of the defect to be repaired on the version to be released from the to-be-repaired status to the main-branch repaired status.

[0107] The defect to be repaired can be associated with multiple versions. Based on the at least one associated version corresponding to the defect to be repaired, branch repairs for the release branches respectively corresponding to each of the associated versions can be automatically created. Among them, the associated version corresponding to the defect can be the version affected by the defect, such as the version containing the defect.

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

[0109] Optionally, all associated versions can be used as the target associated versions; or some of the associated versions can be used as the target associated versions. For example, after determining multiple associated versions, the multiple associated versions can be presented to the reviewer, and based on the reviewer's selection operation for the multiple associated versions (for example, some versions may not have a release plan in the near future), the associated versions selected by the reviewer can be used as the target associated versions.

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

[0111] It should be noted that the creation of the branch repair of the release branch of each associated version and the completion of the branch repair of the release branch of each target associated version can be implemented on the management system or on the associated system. However, whether it is an operation 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 with corresponding relationships in the management system and the associated system. In the embodiments of the present disclosure, based on the operation event of the original defect entity corresponding to the defect to be repaired in the associated system, the real-time automatic update of the defect repair status of the defect to be repaired on the version to be released in the management system realizes the tracking of the defect repair situation of each defect on each version, and at the same time maintains the status consistency between each original entity in the associated system and each corresponding conceptual entity in the management system.

[0112] Furthermore, by establishing the association relationship between the defect and the version, after the trunk repair of the defect is completed, the branch repair of the release branches of multiple associated versions related to the defect can be automatically created, and the branch repair of the release branches of multiple target associated versions can be automatically completed, realizing the automatic branch repair 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 promote the repair progress of defects on multiple versions and improve the efficiency of version release.

[0113] As an alternative embodiment, the method further includes:

[0114] Regarding the defects other than the first defect among the multiple defects to be repaired in the version to be released as the second defect;

[0115] After the next version corresponding to the version to be released is created, the next version is taken as the associated version for each second defect, and the defect repair status of each second defect on the next version is set to the to-be-repaired status;

[0116] Among them, the next version corresponding to the version to be released is the version obtained by updating on the basis of the version to be released.

[0117] Specifically, for multiple defects to be repaired in the version to be released, the defects other than the first defect among these multiple defects to be repaired are taken as the second defects, that is, the defect repair status of the second defects in the version to be released is not the to-be-released status, and the second defects will not be released along with the release branch of the version to be released.

[0118] There is an inheritance relationship between each version of the software, that is, the versions released later will be improved on the basis of the previous versions. The version obtained by updating on the basis of the version to be released is taken as the next version of the version to be released.

[0119] For example, if the version number of the version to be released is 7.2.5, then the version number of the next version of the version to be released is 7.2.6. That is to say, if the version number of the version to be released is expressed as the 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.

[0120] Since the second defects are not released along 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 repair these second defects. That is to say, these second defects are associated with the next version of the version to be released.

[0121] For each second defect, the next version of the version to be released can be taken as the associated version corresponding to the second defect, and the defect repair status of the second defect on the next version is set to the to-be-repaired status. For example, the version identifier of the next version can be added to the version association information corresponding to the second defect.

[0122] It should be noted that when the previous version of the version to be released is released, the previous version can be taken as the version to be released in the release operation of the previous version, and the version to be released can be taken as the next version in the release operation of the previous version. According to the above steps, the automatic establishment of the association relationship between the version to be released and multiple defects can be realized.

[0123] In the embodiments of the present disclosure, for the second defects that are not repaired and inherited from the to-be-released version in the next version, the next version is automatically associated with the second defects, thereby realizing the automatic establishment of the association relationship between the defects and the versions. There is no need for R & D personnel to manually add the defect corresponding associated version identifier, reducing the workload of R & D personnel, saving a large amount of labor costs and time, and improving efficiency.

[0124] As an alternative embodiment, the method further includes:

[0125] If a defect creation event for the to-be-released version is received from an association system, determine the newly added third defects in the to-be-released version based on the defect creation event;

[0126] For each third defect, obtain at least one associated version corresponding to the third defect, and set the defect repair status of the third defect on each corresponding associated version to the to-be-repaired status; the at least one associated version includes the to-be-released version.

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

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

[0129] 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 respectively.

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

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

[0132] In an embodiment of the present disclosure, based on a defect creation event for a to-be-released version sent by an association system, a management system synchronizes and adds a third defect corresponding to the to-be-released version, and establishes an association relationship between the added third defect and multiple versions, so as to perform version management based on the association relationship between the defect and the version subsequently.

[0133] As an alternative embodiment, determining that a defect to be repaired has been repaired on the main trunk based on a main-trunk repair event for the defect to be repaired includes:

[0134] Responding to a defect closing event for the defect to be repaired, it is determined that the defect to be repaired has been repaired on the main trunk of the to-be-released version;

[0135] The defect closing event for the defect to be repaired is triggered after each main-trunk repair event corresponding to the defect to be repaired.

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

[0137] Optionally, the association system can automatically trigger a defect closing event for the defect to be repaired after receiving all the main-trunk repair operations for the defect to be repaired, or a developer can create a defect closing event for the defect to be repaired after determining that the main-trunk repair of the defect to be repaired in the association system has been completed. The association system sends the generated defect closing event to the management system.

[0138] Optionally, after receiving all the main-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 main trunk and automatically trigger a defect closing event for the defect to be repaired, or after receiving all the main-trunk repair events corresponding to the defect to be repaired, a developer can confirm that the defect to be repaired has been repaired on the main trunk in the management system and create a defect closing event for the defect to be repaired.

[0139] It should be noted that the defect closing event can be generated on the management system or on the association system. However, whether it is an operation on a conceptual entity in the management system or an original entity in the association system, it needs to be synchronized to the corresponding entity in the other system to maintain the consistency between the entities with corresponding relationships in the management system and the association system.

[0140] Based on the defect closing event for the defect to be repaired, the management system can determine that the trunk repair of the defect to be repaired is completed, and then can update the defect repair status of the defect to be repaired on the to-be-released version from the to-be-repaired status to the trunk repaired status, thus realizing the real-time automatic update of the defect repair status of defects in the management system on each version.

[0141] As an alternative embodiment, the multiple defects to be repaired in the to-be-released version are determined in the following manner:

[0142] Obtain multiple initial defects related to the to-be-released version;

[0143] For each initial defect, if the admission permission information of the initial defect on the to-be-released version is admission, and the defect repair status of the initial defect on the to-be-released version is the to-be-repaired status, then the initial defect is used as the defect to be repaired in the to-be-released version.

[0144] Specifically, the management system includes multiple defects to be managed. 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 defect to be managed respectively.

[0145] Among the multiple defects to be managed in the management system, the defects to be managed whose associated version information includes the version identifier corresponding to the to-be-released version can be used as the initial defects related to the to-be-released version.

[0146] Among them, the multiple initial defects related to the to-be-released version include the defects with incomplete repairs inherited by the to-be-released version from the corresponding previous version, and the newly added defects in the to-be-released version. For the establishment of the association relationship between the defects and the versions, reference can be made to the description of the corresponding embodiments in the foregoing text, which will not be elaborated here.

[0147] After obtaining the multiple initial defects of the to-be-released version, among the multiple initial defects, the initial defects whose admission permission information on the to-be-released version is admission and whose defect repair status on the to-be-released version is the to-be-repaired status can be used as the defects to be repaired in the to-be-released version.

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

[0149] Optionally, the admission permission information of the initial defects on the version to be released can be determined in the following manner: after determining multiple initial defects of the version to be released, the multiple initial defects can be presented to the defect reviewers, and the defect reviewers input the admission permission information of each initial defect on the version to be released; it can also be that the defect reviewers obtain multiple defects to be managed in the management system, and for each defect to be managed, the defect reviewers input the admission permission information of the defect to be managed on its multiple versions. The embodiments of the present disclosure do not limit this.

[0150] In the embodiments of the present disclosure, by obtaining multiple initial defects related to the version to be released, and based on the admission permission information of each initial defect on the version to be released and the defect repair status on the version to be released, the association relationship between the defects and the versions, as well as the defect repair status of the defects on the versions, are utilized to automatically screen out multiple defects to be repaired in the version to be released, so as to subsequently promote the repair progress of the defects to be repaired, improving the efficiency of version release.

[0151] As an alternative embodiment, the method further includes:

[0152] In response to the version creation event to be released, create the version to be released, as well as the release branch corresponding to the version to be released, and set the version status of the version to be released to the active state;

[0153] Release the release branch corresponding to the version to be released, and then it further includes:

[0154] Update the version status of the version to be released from the active state to the released state.

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

[0156] 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 state to the released state.

[0157] In the embodiments of the present disclosure, by automatically creating the 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, further reducing the manual operation cost and improving the efficiency; by setting the version status corresponding to the version, tracking the release situation of each version based on the version status corresponding to the version is beneficial to the management of multiple versions.

[0158] Figure 4 A schematic diagram of entity status update provided by an embodiment of the present disclosure, as Figure 4 shown, the automatic update process of the version status of the version to be released in the management system and the defect repair status of the defects to be repaired in the version to be released on the version to be released includes:

[0159] 1. In response to the version creation event of the version to be released by the release personnel, when the management system creates the version to be released, the version status of the version to be released enters the active state, and at the same time, the management system automatically creates the corresponding release branch;

[0160] 2. The R & D personnel create the original defect entity for the version to be released in the associated system (i.e., the newly added defects 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 the corresponding defect concept entity as the defect to be repaired in the version to be released, and obtains the associated version information of the defect to be repaired, and sets the defect repair status of the defect to be repaired in the version to be released to the to-be-repaired status;

[0161] 3. The R & D personnel can create the trunk repair for the original defect entity corresponding to the defect to be repaired in the associated system. After the trunk repair is completed in the associated system, it will send the trunk repair event for the defect to be repaired to the management system. Based on the received trunk repair event, 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 to-be-repaired status to the trunk-repaired status;

[0162] 4. Based on at least one associated version corresponding to the defect to be repaired, the management system can automatically create the branch repair for each of the respective release branches corresponding to the associated versions. The target associated version can be selected from multiple associated versions, and the target associated version includes the version to be released; the trunk repair of the defect to be repaired in the version to be released can be merged into the release branch of the defect to be repaired in the version to be released to complete the branch repair of the defect to be repaired on the release branch of the version to be released, and the defect repair status of the defect to be repaired in the version to be released is updated from the trunk-repaired status to the to-be-released status;

[0163] 5. When the management system detects that the release conditions corresponding to the version to be released are met, it releases the release branch of the version to be released, releases the defect to be repaired together with the release branch, and updates the defect repair status of the defect to be repaired in the version to be released from the to-be-released status to the repaired status.

[0164] So far, during the process of a version release operation, the status update of the version to be released and the defect to be repaired ends.

[0165] 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:

[0166] 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;

[0167] 2. R&D personnel mark the associated versions of the defect: R&D personnel mark the defect with "affects-{version number}";

[0168] 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;

[0169] 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.

[0170] 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.

[0171] 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.

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

[0173] 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.

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

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

[0176] Among them, the data storage module needs to maintain system entity data, including defect information, version information, PR information, and the association relationships between entities. When the system receives a new entity event or responds through the user interface module, data updates need to be performed through the data storage module.

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

[0178] The event receiving module is used to receive entity operation events and record them in the system, such as operations related to defects and PR additions in an associated system (taking Github as an example). After being processed by the status change module, the event entity information will be saved in the data storage module. The event receiving module has an event listening mechanism and can receive event requests when operations occur in the associated system. To receive events from the associated system, an HTTP address for receiving events needs to be configured for this system on the associated system.

[0179] The status change module is responsible for tracking the status changes of each entity in the system to ensure the correctness and consistency of status changes. Whenever an event is triggered, this module will make status changes to the relevant entities and store them using the data storage module. At the same time, if the relevant status changes cause changes in the status of other entities, the status change module will request the entity operation module to make change operations on the entities in the associated system.

[0180] The entity operation module implements the specific operation logic for the associated system. When the status of an entity in this system changes, it needs to be reflected in the associated system through the entity operation module to ensure that the entity statuses of the associated system and this system are consistent.

[0181] Figure 8 A schematic diagram of a process for creating a version provided by an embodiment of the present disclosure. As Figure 8As shown in the figure, the management staff 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 status change module creates a release branch BranchX for version VersionX, synchronously creates release branch BranchX' in the associated system through the entity operation module, and calls the data storage module to store the branch information.

[0182] Figure 9 The figure is a schematic flowchart of a process for creating a defect provided by an embodiment of the present disclosure. As Figure 9 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 status change module to synchronously create the corresponding defect IssueX' in the management system, and stores the defect information through the data storage module.

[0183] The R & D personnel mark "affect-versionX" on the defect. 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 association information between the defect and the version through the data storage module. Users can query the relevant information of the version and the defect in the defect management view and the defect details view of the user interface module.

[0184] Figure 10 The figure is a schematic flowchart of a process for trunk repair provided by an embodiment of the present disclosure. As Figure 10 shown, the R & D personnel create a repair PullRequestX (i.e., trunk repair) on the associated system. 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 status 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 association information between 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 details view of the user interface module.

[0185] Figure 11 The figure is a schematic flowchart of a process for branch repair provided by an embodiment of the present disclosure. As Figure 11As shown, the R & D personnel completed the repair of PullRequestX and closed the defect IssueX on the associated system. The management system received the repair event of PullRequestX and the closing event of defect IssueX through the event receiving module, and passed them to the status change module. The status change module determined that the repair had been completed on the main branch, called the data storage module to store the main branch repair information, obtained the association information between defect IssueX and version VersionX through the data storage module, called the entity operation module to create a branch repair PullRequestY on BranchX based on the repair of PullRequestX, and synchronized the creation of a branch repair on the associated system through the entity operation module.

[0186] The R & D personnel completed the merge operation of the branch repair PullRequestY on the associated system. The management system received the corresponding event through the event receiving module, set the defect repair status of defect IssueX on version VersionX to the to-be-released status through the status change module, and called the data storage module to store the version repair information.

[0187] Figure 12 A flowchart of a version release provided by an embodiment of the present disclosure is as Figure 12 shown. The management personnel set the version status of VersionX to the released status through the user interface module. The management system set the status of all defects with completed repairs (including defect IssueX) on VersionX to the repaired status through the status change module, and called the data storage module to store the version release information. The status change module set the status of the repaired defects to the released status and called the data storage module to store the released defect information. The status change module integrated the unrepaired defects into the next version and called the storage module to store the unrepaired defect information.

[0188] The management system provided by an embodiment of the present disclosure is a multi-version management system centered on defects. "Centered on defects" 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 the R & D personnel marking the "affected version identifier" on the defects; the association between defects and repairs can be associated by the R & D personnel marking the "associated defect" on the repairs. Repairs include main branch repairs and release branch repairs. Main branch repairs are not directly associated with versions, and release branch repairs are repairs made on the corresponding version branch by the main branch repair according to the "affected version identifier" of the associated defect.

[0189] By automatically establishing and maintaining the associations among defects, versions, and fixes; based on these associations, realizing the automatic transfer and update of entity states; and providing multi-dimensional views based on the associations, such as version views and defect views.

[0190] The management system provided by the embodiments of the present disclosure supports the quick inheritance, management, and release status management of the same defect by multiple versions. Additionally, the release status of the same defect in different versions is automatically judged by the management system through the completion status of the associated fixes, thereby maintaining the release status of different versions centered around a defect and enabling querying of the list of multiple versions output from the perspective of a single defect, reducing a large amount of manual operations on defects.

[0191] Figure 13 The structure diagram of a version management device provided by the embodiments of the present disclosure is as Figure 9 shown. The device of this embodiment may include:

[0192] A determination module 210, configured to determine a version to be released and multiple defects to be fixed in the version to be released, where the defect repair status of the defects to be fixed in the version to be released is the to-be-fixed status;

[0193] A status update module 220, configured to, for each defect to be fixed, if the repair of the release branch of the defect to be fixed in the version to be released is completed, update the defect repair status of the defect to be fixed in the version to be released from the to-be-fixed status to the to-be-released status;

[0194] A first defect determination module 230, configured to use the defects to be fixed whose defect repair status is updated to the to-be-released status among the multiple defects to be fixed as the first defects;

[0195] A version release module 240, configured to, if the release conditions corresponding to the version to be released are met, release the release branch corresponding to the version to be released, 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 status to the fixed status.

[0196] As an optional embodiment, the management system is used to manage an associated system;

[0197] When the status update module updates the defect repair status of the defect to be fixed in the version to be released from the to-be-fixed status to the to-be-released status if the repair of the release branch of the defect to be fixed in the version to be released is completed, it is specifically configured to:

[0198] If it is determined that the defect to be repaired has been repaired on the main trunk based on the main trunk repair event for the defect to be repaired, update the defect repair status of the defect to be repaired on the to-be-released version from the to-be-repaired status to the main trunk repaired status;

[0199] The main trunk repair event of the defect to be repaired is triggered when the associated system receives the main trunk repair for the original defect entity corresponding to the defect to be repaired; the main trunk repair event includes information about the defect to be repaired;

[0200] Based on at least one associated version corresponding to the defect to be repaired, create branch repairs for the release branches respectively corresponding to each associated version.

[0201] Determine a target associated version from each associated version; the target associated version includes the to-be-released version;

[0202] For each target associated version, based on the branch repair of the release branch of the target associated version, repair the release branch of the target associated version, and update the defect repair status of the defect to be repaired on the target associated version from the main trunk repaired status to the to-be-released status.

[0203] As an optional implementation example, the device further includes:

[0204] A first association relationship establishment module, configured to use the defects other than the first defect among the multiple defects to be repaired of the to-be-released version as the second defects;

[0205] After the next version corresponding to the to-be-released version is created, use the next version as the associated version corresponding to each second defect, and set the defect repair status of each second defect on the next version to the to-be-repaired status;

[0206] Wherein, the next version corresponding to the to-be-released version is a version obtained by updating based on the to-be-released version.

[0207] As an optional embodiment, the device further includes:

[0208] A second association relationship establishment module, configured to, if receiving a defect creation event for the to-be-released version sent by the associated system, determine a third defect newly added in the to-be-released version based on the defect creation event;

[0209] For each third defect, obtain at least one associated version corresponding to the third defect, and set the defect repair status of the third defect on each corresponding associated version to the to-be-repaired status; the at least one associated version includes the to-be-released version.

[0210] As an alternative embodiment, when the status update module determines that the defect to be repaired has been repaired on the main trunk based on the main trunk repair event for the defect to be repaired, it is specifically configured to:

[0211] In response to the defect closing event for the defect to be repaired, it is determined that the defect to be repaired has been repaired on the main trunk of the version to be released;

[0212] The defect closing event for the defect to be repaired is triggered after each main trunk repair event corresponding to the defect to be repaired.

[0213] As an alternative embodiment, the device further includes a defect to be repaired determination module, configured to:

[0214] Obtain a plurality of initial defects related to the version to be released;

[0215] 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 the status to be repaired, then the initial defect is used as the defect to be repaired of the version to be released.

[0216] As an alternative embodiment, the device further includes a version creation module, configured to:

[0217] In response to the version to be released creation event, create the version to be released, as well as the release branch corresponding to the version to be released, and set the version status of the version to be released to the active status;

[0218] The version status update module is configured to update the version status of the version to be released from the active status to the released status.

[0219] As an alternative embodiment, the associated system includes a plurality of original defect entities, a plurality of original repair entities, and a plurality of original version entities; the plurality of defects to be managed in the management system include a plurality of defect concept entities respectively corresponding to the plurality of original defect entities; the plurality of repairs to be managed in the management system include a plurality of repair concept entities respectively corresponding to the plurality of original repair entities; the plurality of versions to be managed in the management system include a plurality of version concept entities respectively corresponding to the plurality of original version entities;

[0220] The status updates of each entity in the associated system and each concept entity respectively corresponding to each entity in the management system are synchronized.

[0221] The device according to the embodiments of the present disclosure can execute the method provided by the embodiments of the present disclosure. Their implementation principles are similar and have corresponding technical effects. The actions performed by each module in the device according to the embodiments of the present disclosure correspond to the steps in the method according to the embodiments of the present disclosure. For the detailed function descriptions of the modules of the device, reference can specifically be made to the descriptions in the corresponding methods shown above, and will not be elaborated here.

[0222] In the embodiments of the present disclosure, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other relevant parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), 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 a part of the overall module or unit that includes the function of the module or unit.

[0223] In the embodiments of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory. The processor executes the above 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 realized 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 tracking of the defect repair situation of each defect on each version is realized. 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 developers to manually update and align the repair progress of each defect on each version, the version management method provided by the embodiments of the present disclosure does not require developers to manually update and align the defect repair situation of each defect on each version, saving a large amount of labor costs and time and improving the efficiency of version management. Further, the first defects that have been repaired are automatically determined according to the defect repair status of each defect to be repaired on the version to be released, and the first defects are 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 developers' operation mistakes or omissions on the version quality and ensures the quality of the released version.

[0224] In an optional embodiment, an electronic device is provided, as Figure 14 shown Figure 14The illustrated electronic device 4000 includes: a processor 4001 and a memory 4003. Among them, the processor 4001 and the memory 4003 are connected, such as being connected through a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, and the transceiver 4004 can be used for data interaction between this electronic device and other electronic devices, such as data transmission and / or data reception, etc. It should be noted that in practical applications, the transceiver 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation to the embodiments of the present disclosure.

[0225] The processor 4001 can be a CPU (Central Processing Unit, central processor), a general-purpose processor, a DSP (Digital Signal Processor, data signal processor), an ASIC (Application Specific Integrated Circuit, application-specific integrated circuit), an FPGA (Field Programmable Gate Array, field programmable gate array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in combination with the content disclosed in the present disclosure. The processor 4001 can also be a combination that realizes computing functions, such as a combination including one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0226] The bus 4002 may include a path for transmitting information between the above components. The bus 4002 can be a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus or an EISA (Extended Industry Standard Architecture, extended industry standard architecture) bus, etc. The bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 14 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0227] The memory 4003 can 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. It can also be an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store a computer program and can be read by a computer, which is not limited here.

[0228] The memory 4003 is used to store the computer program for implementing the embodiments of the present disclosure and is controlled by the processor 4001 for execution. The processor 4001 is used to execute the computer program stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0229] Among them, the electronic device includes but is not limited to: mobile terminals such as mobile phones, laptop computers, 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.

[0230] The embodiments of the present disclosure provide 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 content shown in the foregoing method embodiments can be implemented.

[0231] The embodiments of the present disclosure also provide a computer program product, including a computer program. When the computer program is executed by a processor, the steps and corresponding content shown in the foregoing method embodiments can be implemented.

[0232] It should be understood that although the flowchart of the embodiments of the present disclosure indicates each operation step by an arrow, the execution order of these steps is not limited to the order indicated by the arrow. Unless there is a clear description in this article, in some implementation scenarios of the embodiments of the present disclosure, the implementation steps in each flowchart can be executed in other orders according to requirements. 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 among these sub-steps or stages can also be executed at different times respectively. In the scenario where the execution times are different, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and the embodiments of the present disclosure do not limit this.

[0233] The above are only optional implementation manners of some implementation scenarios of the present disclosure. It should be noted that for those of ordinary skill in the art, without departing from the technical concept of the solution of the present disclosure, using other similar implementation means based on the technical idea of the present disclosure also belongs to the protection scope of the embodiments of the present disclosure.

Claims

1. A version management method, characterized in that, Applied to a management system for managing an associated system, including: Determine the version to be released in the management system and multiple defects to be fixed in the version to be released, where the defect repair status of the defects to be fixed in the version to be released is the to-be-fixed status; For each defect to be fixed, if the repair on the release branch of the defect to be fixed in the version to be released is completed, update the defect repair status of the defect to be fixed in the version to be released from the to-be-fixed status to the to-be-released status; Take the defects to be fixed whose defect repair status is updated to the to-be-released status among the multiple defects to be fixed as the first defects; If the release conditions corresponding to the version to be released are met, release the release branch corresponding to the version to be released, 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 status to the fixed status; The step of, if the repair on the release branch of the defect to be fixed in the version to be released is completed, updating the defect repair status of the defect to be fixed in the version to be released from the to-be-fixed status to the to-be-released status, includes: If it is determined that the defect to be fixed has been repaired on the main trunk based on the main-trunk repair event for the defect to be fixed, update the defect repair status of the defect to be fixed in the version to be released from the to-be-fixed status to the main-trunk-fixed status; the main-trunk repair event of the defect to be fixed is triggered when the associated system receives the main-trunk repair for the original defect entity corresponding to the defect to be fixed; the main-trunk repair event includes information about the defect to be fixed; Based on at least one associated version corresponding to the defect to be fixed, create branch repairs for the release branches respectively 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, repair the release branch of the target associated version based on the branch repair of the release branch of the target associated version, and update the defect repair status of the defect to be fixed in the target associated version from the main-trunk-fixed status to the to-be-released status.

2. The method according to claim 1, wherein The method further includes: Take the defects other than the first defects among the multiple defects to be fixed in the version to be released as the second defects; After the next version corresponding to the version to be released is created, take the next version as the associated version corresponding to each second defect, and set the defect repair status of each second defect in the next version to the to-be-fixed status; Wherein, the next version corresponding to the version to be released is the version obtained by updating on the basis of the version to be released.

3. The method according to claim 1, characterized in that, The method further includes: If a defect creation event for the version to be released sent by the associated system is received, determine the newly added third defects in the version to be released based on the defect creation event; For each third defect, obtain at least one associated version corresponding to the third defect, and set the defect repair status of the third defect on each corresponding associated version to the to-be-fixed status; the at least one associated version includes the version to be released.

4. The method according to claim 1, characterized in that 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 closure event for the defect to be repaired, it is determined that the defect to be repaired has been repaired on the trunk of the version to be released; The defect closure event for the defect to be repaired is triggered after each trunk repair event corresponding to the defect to be repaired.

5. The method according to claim 1, characterized in that, The multiple defects to be repaired in the version to be released are determined in the following manner: Obtain multiple initial defects related to the version to be released; For each initial defect, if the admission permission information of the initial defect in the version to be released is admission, and the defect repair status of the initial defect in the version to be released is the status to be repaired, then the initial defect is used as a defect to be repaired in the version to be released.

6. The method according to claim 1, wherein The method further includes: In response to an event of creating a version to be released, create the version to be released, as well as the release branch corresponding to the version to be released, and set the version status of the version to be released to the active state; After releasing the release branch corresponding to the version to be released, it further includes: Update the version status of the version to be released from the active state to the released state.

7. According to the method described in claim 1, 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 respectively corresponding to the multiple original defect entities; the multiple repairs to be managed in the management system include multiple repair concept entities respectively corresponding to the multiple original repair entities; the multiple versions to be managed in the management system include multiple version concept entities respectively corresponding to the multiple original version entities; The status update of each entity in the association system and each concept entity corresponding to each entity in the management system respectively is synchronized.

8. A version management device, characterized in that, It includes: A determination module, configured to determine the version to be released in the management system, and multiple defects to be repaired in the version to be released, where the defect repair status of the defects to be repaired in the version to be released is the status to be repaired; A status update module, configured to, for each defect to be repaired, if the repair of the release branch of the defect to be repaired in the version to be released is completed, update the defect repair status of the defect to be repaired in the version to be released from the status to be repaired to the status to be released; A first defect determination module, configured to use the defects to be repaired whose defect repair status is updated to the status to be released among the multiple defects to be repaired as the first defects; A version release module, configured to, if the release conditions corresponding to the version to be released are met, release the release branch corresponding to the version to be released, 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 status to be released to the status of having been repaired; When the status update module updates the defect repair status of the defect to be repaired in the version to be released from the status to be repaired to the status to be released if the repair of the release branch of the defect to be repaired in the version to be released is completed, it is used for: If it is determined that the defect to be repaired has been repaired on the main trunk based on the main trunk repair event for the defect to be repaired, update the defect repair status of the defect to be repaired in the version to be released from the to-be-repaired status to the main-trunk-repaired status; The main trunk repair event of the defect to be repaired is triggered when the associated system receives the main trunk repair for the original defect entity corresponding to the defect to be repaired; the main 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 repaired, create branch repairs for the release branches respectively 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, repair the release branch of the target associated version based on the branch repair of the release branch of the target associated version, and update the defect repair status of the defect to be repaired in the target associated version from the main-trunk-repaired status to the to-be-released status.

9. An electronic device, comprising a memory, a processor, and a computer program stored on 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 7.

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

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 7.

Images