Software version information management method and device, equipment, medium and product

Abstract

The invention relates to a software version information management method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: receiving a version information generation request for a target component in target equipment; the version information generation request carries a project identifier of a target project to which the target component belongs; acquiring a project lock corresponding to the project identifier; under the condition that the item lock is successfully acquired, updating the current serial number of the counter corresponding to the item identifier in the current generation period; the counter is used for recording the number of times that the item identifier generates new version information in the current generation period; generating target version information corresponding to the target component according to the current serial number, the current generation period and the item identifier of the counter; and after the target version information is generated, releasing the item lock. By adopting the method, the global uniqueness of the version information can be realized in a high-concurrency construction scene.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a software version information management method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] In modern automotive electronic systems, the vehicle contains controllers for multiple functional domains. As the complexity of vehicle software increases and the frequency of version iterations rises, the software versions of these controllers need to be managed uniformly and traceable to ensure the consistency and security of the vehicle integration.

[0003] In traditional technologies, version information management for automotive controller software typically relies on continuous integration systems to read existing version information from external artifact repositories or file systems, and then incrementally generate new version information based on this.

[0004] However, existing methods for managing version information of automotive controller software generally suffer from problems such as complex generation processes, high risk of concurrency conflicts, and poor traceability. Therefore, they cannot meet the management requirements of generating unique version information for in-vehicle software systems in high-concurrency construction scenarios. Summary of the Invention

[0005] Therefore, it is necessary to provide a software version information management method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can generate unique version information in high-concurrency construction scenarios to address the above-mentioned technical problems.

[0006] Firstly, this application provides a software version information management method, including:

[0007] Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project to which the target component belongs;

[0008] Obtain the project lock corresponding to the project identifier;

[0009] If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0010] Based on the current serial number, current generation cycle, and project identifier of the counter, generate the target version information corresponding to the target component;

[0011] After generating the target version information, release the project lock.

[0012] In one embodiment, if the project lock is successfully acquired, the current sequence number of the counter corresponding to the project identifier in the current generation cycle is updated, including: if the project lock is successfully acquired, obtaining the recycling version information of the target component under the target project; if the recycling version information fails to be obtained, updating the current sequence number of the counter corresponding to the project identifier in the current generation cycle.

[0013] In one embodiment, the method further includes: if the version information is successfully acquired, updating the status of the version information; and using the updated version information as the target version information corresponding to the target component.

[0014] In one embodiment, the method further includes: receiving a request to reclaim historical version information of a target component under a target project; and using the historical version information as the reclaimed version information of the target component under the target project.

[0015] In one embodiment, the method further includes: if acquiring the project lock fails, determining the current holding time of the project lock; determining a target waiting time based on the current holding time and the effective duration threshold of the project lock; and reacquiring the project lock after waiting for the target waiting time.

[0016] In one embodiment, target version information corresponding to the target component is generated based on the current serial number of the counter, the current generation cycle, and the project identifier. This includes: obtaining software description information associated with the project identifier; and combining the current serial number of the counter, the current generation cycle, and the software description information according to the data structure of the version information to obtain the target version information corresponding to the target component.

[0017] Secondly, this application also provides a software version information management device, comprising:

[0018] The receiving module is used to receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project.

[0019] The acquisition module is used to acquire the project lock corresponding to the project identifier.

[0020] The update module is used to update the current sequence number of the counter corresponding to the project identifier in the current generation cycle when the project lock is successfully acquired; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0021] The generation module is used to generate target version information corresponding to the target component based on the current serial number of the counter, the current generation cycle, and the project identifier.

[0022] The management module is used to release the project lock after the target version information is generated.

[0023] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0024] Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project;

[0025] Obtain the project lock corresponding to the project identifier;

[0026] If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0027] Based on the current serial number, current generation cycle, and project identifier of the counter, generate the target version information corresponding to the target component;

[0028] After generating the target version information, release the project lock.

[0029] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0030] Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project;

[0031] Obtain the project lock corresponding to the project identifier;

[0032] If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0033] Based on the current serial number, current generation cycle, and project identifier of the counter, generate the target version information corresponding to the target component;

[0034] After generating the target version information, release the project lock.

[0035] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0036] Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project;

[0037] Obtain the project lock corresponding to the project identifier;

[0038] If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0039] Based on the current serial number, current generation cycle, and project identifier of the counter, generate the target version information corresponding to the target component;

[0040] After generating the target version information, release the project lock.

[0041] The aforementioned software version information management methods, devices, computer equipment, computer-readable storage media, and computer program products, by introducing a project lock mechanism, ensure the atomicity of version information generation operations in high-concurrency construction scenarios and reduce the risk of version number duplication conflicts. By using the project identifier and generation cycle as the core parameters for generating version information, globally unique and uniformly formatted version identifiers are generated for all controllers under the same project, achieving unique consistency of software version information for different controllers under the same project and improving the generation efficiency of vehicle controller version information. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a schematic diagram of the architecture of a software version information management method in one embodiment;

[0044] Figure 2 This is a flowchart illustrating a software version information management method in one embodiment;

[0045] Figure 3 This is a flowchart illustrating a software version information management method in another embodiment;

[0046] Figure 4 This is a schematic diagram of the overall process of a software version information management method in one embodiment;

[0047] Figure 5 This is a flowchart illustrating the software version information management method in yet another embodiment;

[0048] Figure 6 This is a structural block diagram of a software version information management device in one embodiment;

[0049] Figure 7This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0052] To facilitate understanding, we will first explain the software version information management architecture. For example... Figure 1 As shown, the software version information management architecture includes a build system, a version information processing system, and a vehicle controller (Electronic Control Unit, ECU). The build system initiates version information generation requests to the version information processing system. The version information processing system responds to the version information generation requests and generates the required version information. The version information processing system includes a Raft (RaftConsensus Algorithm) distributed lock, a version pool, and a counter. The Raft distributed lock ensures the uniqueness of the generated version information. The version pool manages reclaimable version information to achieve resource reuse, and the version pool can be implemented using a FIFO (First In First Out) queue. The counter generates a new, auto-incrementing revision number when no reclaimable version is available. The ECU receives new version information and writes it to the ECU's Flash software identifier area, the data area corresponding to the Diagnostic Information Diagnostic (DID, such as F189), and the CAN (Controller Area Network) message signal buffer to achieve synchronization of version information across the ECU's internal storage, diagnostic interface, and CAN bus. It is worth noting that the build system, version information processing system, and vehicle controller can be deployed on different terminals or servers to form a distributed architecture; alternatively, the build system and version information processing system can be deployed on the same terminal or server, and this application does not impose any restrictions on this.

[0053] Based on the above software version information management, in an exemplary embodiment, such as Figure 2 As shown, a software version information management method is provided. This method can be applied to computer devices, which can be terminals or servers. Taking the application of this method to a terminal where a version information processing system is deployed as an example, the method includes:

[0054] S201, Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project to which the target component belongs.

[0055] The target device can be a complete vehicle equipped with multiple functional domain controllers; the target component can be a vehicle controller within the vehicle that requires software version information generation, such as an electronic control unit (ECU), body control module, gateway control module, powertrain domain controller, and chassis domain controller; the version information generation request can be a request initiated by the build system to apply for the software version identifier corresponding to the target component; the target project can be a system or software product that requires multi-component collaborative version management, i.e., a research and development project that includes multiple components and requires unified management of the software version information of the components, such as: vehicle subsystem research and development projects (such as intelligent cockpit subsystem projects and autonomous driving domain controller projects) and equipment software research and development projects in other fields (such as control system research and development projects for industrial equipment); the project identifier can be a unique identifier for the target project, used to associate resources such as locks, counters, and version pools corresponding to the project. It is worth noting that a target project contains one or more target components; for a single version generation request, each target component can have only one target project to which it belongs.

[0056] Optionally, the system determines the target component in the target device to which version information needs to be generated, and determines the vehicle software development project to which it belongs. It then generates and sends a version information generation request carrying the unique identifier of the project to the version information processing system. The version number processing system receives the version information generation request, thereby triggering the subsequent version information generation process.

[0057] S202, obtain the project lock corresponding to the project identifier.

[0058] Among them, the project lock can be a distributed mutex lock associated with the project identifier, used to ensure that no duplicate version numbers are generated when multiple tasks make requests at the same time.

[0059] Optionally, to further ensure the atomicity and global uniqueness of the version information generation process, this implementation can adopt a lock mechanism based on the Raft distributed consistency protocol (etcd, a distributed key-value storage system). Leveraging etcd's strong consistency characteristics, it can ensure the global uniqueness of the lock state in scenarios with multi-node deployment and concurrent task competition, while also guaranteeing the consistency of version number generation. Furthermore, this project lock is not stored in the local process but is persistently stored in the system's unified shared component, etcd, and its storage structure is represented as follows:

[0060]

[0061] in, It can be a project lock indexed by a project identifier (i.e.) In etcd, the actual content stored is a combination of data containing two fields: Tlock and Token. It can be a distributed project lock corresponding to the target project, with the project identifier as the unique index, and the key name stored in etcd; project can be the project identifier; Tlock can be the system timestamp recorded when the version information processing system successfully acquires the project lock; Token can be a unique random string / numeric code generated when the version number processing system acquires the project lock; since all build tasks and all deployment nodes access this unified data structure in etcd, this lock naturally has distributed mutual exclusion capability.

[0062] It is worth noting that the acquisition of the project lock is achieved through atomic methods, such as... , This can be a distributed atomic method used to acquire the lock of the target project. This method has distributed atomicity, and its core logic is atomic conditional write. It can be defined as follows:

[0063]

[0064] In other words, if the lock corresponding to the item identifier does not exist in etcd, the lock data is atomically written and True is returned (indicating that the lock acquisition was successful); if the lock corresponding to the item identifier already exists in etcd, the atomic write operation fails and True is returned (indicating that the lock acquisition failed).

[0065] Project locks can be acquired by calling... The method takes the target project's project identifier as input and atomically checks if it exists in etcd. (That is, the project lock storage item corresponding to the project identifier); if the lock corresponding to the project does not exist in etcd, the method will atomically transfer the lock data (i.e. The atomic write operation writes the system timestamp (Tlock is the system timestamp and Token is the unique random code) to etcd and returns True, indicating that the project lock was successfully acquired. If the lock for the project already exists in etcd, the atomic write operation will fail directly and return False, indicating that the project lock acquisition failed.

[0066] S203, if the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0067] The current generation period can be a time-dimension unit for version information generation (such as a period divided by natural days), and the counter counts independently within the same period; the current sequence number can be the value currently recorded by the counter; the data structure of the counter can be: ; This is a version number counter; N is the current value of the counter, which can be an integer (Sequence) and is used to generate a sequence value for new version information, ensuring its uniqueness.

[0068] Optionally, after successfully acquiring the project lock corresponding to the project identifier, the version information processing system obtains the counter corresponding to the project identifier in the current generation cycle, and increments the counter value to update its current sequence number. This counter is used to record the cumulative number of new version information generated for the project identifier in the current generation cycle. Specifically: the version information processing system first determines the identifier corresponding to the current generation cycle (e.g., when divided by calendar days, the current system date is taken as the value of date); then, based on the target project's project identifier and the determined date, it locates the corresponding counter storage item in distributed storage (e.g., etcd). Leveraging the atomic read capability of distributed storage, the current value N of the counter (i.e., the number of times version information has been generated in the current period) is obtained; an atomic increment operation is performed on the current value N of the counter (i.e., N = N + 1); finally, the incremented value (N + 1) is written back. In the corresponding storage item, the current sequence number is updated.

[0069] S204. Based on the current serial number of the counter, the current generation cycle, and the project identifier, generate the target version information corresponding to the target component.

[0070] The target version information can be a unique software version identifier generated for the target component, including but not limited to version number, version type identifier, version build timestamp, version compatible hardware model, and version status identifier.

[0071] Optionally, after updating the current serial number of the counter corresponding to the current generation cycle of the project identifier, the version number processing system extracts the current serial number of the counter, the current generation cycle, and the project identifier, and generates target version information that uniquely corresponds to the target component.

[0072] In one embodiment, the method for generating target version information may further include: obtaining software description information associated with the project identifier; and combining the current sequence number of the counter, the current generation cycle, and the software description information according to the data structure of the version information to obtain the target version information corresponding to the target component.

[0073] The software description information can be basic information that corresponds to the project identifier and is used to characterize the core attributes of the software, including but not limited to the software prefix identifier, major version number, software stage code and supplier identifier.

[0074] Optionally, software description information associated with the project identifier is obtained, and then, according to a pre-defined version information data structure, the current serial number of the counter, the current generation cycle, and the software description information are combined and arranged according to a fixed coding rule to finally generate target version information that can uniquely identify the target component software version.

[0075] It is worth noting that this application defines a version information generation model based on a combination of multiple fields. The generation logic of version information V can be expressed as follows:

[0076]

[0077] Where F is the version number combination encoding function; P can be the software prefix identifier SW; M can be the major version number; C can be the software cycle code; D can be the date field, used to reflect the current generation cycle of the version information; X can be the vendor code; and R can be the revision sequence number. Based on the above variables, version information can be arranged in the following format:

[0078]

[0079] Wherein, S is the software prefix identifier, S is the software prefix identifier for the output stage of the version information generation model, and P is the software prefix identifier for the input stage of the version information generation model; that is, P and S are symbolic representations of the same software prefix identifier at different stages.

[0080] For example, the aforementioned auto-incrementing revision number R is generated by an auto-incrementing counter, and its generation logic is defined as follows:

[0081]

[0082] Here, Counter(S, D) represents the current sequence number of the counter corresponding to the software prefix identifier S and the date field D. The counter can be used to realize the auto-increment update of the revision sequence number under the current generation cycle.

[0083] S205: After generating the target version information, release the project lock.

[0084] Optionally, after generating the target version information corresponding to the target component, the version number processing system performs a release operation on the project lock corresponding to the project identifier, marking the project lock as available and accessible to other requests.

[0085] It is worth noting that, to ensure the consistency, stability, and multi-scenario accessibility of the target version information in the vehicle controller (ECU), after generating the target version information, it is also necessary to complete the multi-link storage and synchronization of this version information in the ECU. Specifically, this can be done as follows: the target version information is written into the software identification area of ​​the controller's Flash memory. This area is a fixed read-only area used to store the software version and identification data. During the controller startup process, the version information in the Flash software identification area is copied to the data area corresponding to the diagnostic DID (such as F189), allowing diagnostic services (such as the UDS0x22 service) to access this version information. At the same time, this diagnostic DID supports external diagnostic tools to read the current software version information, enabling external diagnostic traceability of the version. Finally, the target version information is synchronously mapped to the CAN message signal buffer. The system will map the version information stored in Flash to the signal buffer of the CAN communication stack for periodically sending version signals. Its encoding logic can be represented as:

[0086]

[0087] EncodeCAN is the encoding function for CAN signals, and Vcanfd is the encoded CAN message version signal, thereby enabling the broadcast display of the target version information on the vehicle bus.

[0088] The above software version information management method ensures the atomicity of version information generation operations in high-concurrency construction scenarios and reduces the risk of version number duplication by introducing a project lock mechanism. By using the project identifier and generation cycle as the core parameters for generating version information, a globally unique and uniformly formatted version identifier is generated for all controllers under the same project, achieving unique consistency of software version information of different controllers under the same project and improving the generation efficiency of vehicle controller version information.

[0089] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment, in which the step of updating the current sequence number of the counter in S203 is further refined. See Figure 3 The steps for updating the current sequence number shown include:

[0090] S301: If the project lock is successfully acquired, obtain the recycling version information of the target component under the target project.

[0091] The reclaimed version information can be the software version identification information that is in a reclaimed state.

[0092] Optionally, after successfully acquiring the project lock corresponding to the target project, the version number processing system searches the recycling pool associated with the target project to see if there is any software version information in the recycling state. It is worth noting that the recycling pool follows a first-in, first-out (FIFO) logic. For example, it can be implemented using FIFO, or it can be implemented in other ways that follow FIFO logic; this application does not limit this. The data structure of the recycling pool is as follows: ; The version recycling pool is a resource pool identifier used to store information on software versions that have been recycled and are currently idle under the target project; date is the generation cycle index; This is a first-in-first-out (FIFO) queue, the implementation structure of the recycling pool. FIFO stands for First In First Out, and List represents a queue / list, indicating that version information in the recycling pool is redistributed according to the order of "first to recycle, first to reuse".

[0093] S302, if the version information acquisition fails, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle.

[0094] Optionally, when the version number processing system fails to obtain the recycled version information of the target component under the target project, that is, when there is no reusable software version information in the recycling pool associated with the target project, it indicates that new software version information needs to be regenerated. The system then obtains the counter corresponding to the project identifier in the current generation cycle, increments the value of the counter, and completes the update of the current sequence number of the counter.

[0095] In one embodiment, the method for acquiring the project lock may further include: if acquiring the project lock fails, determining the current holding time of the project lock; determining the target waiting time based on the current holding time and the effective duration threshold of the project lock; and reacquiring the project lock after waiting for the target waiting time.

[0096] Among them, the current occupancy duration can be the duration that the project lock has been occupied; the effective duration threshold can be the maximum duration that the project lock can be occupied at one time in a pre-set manner; the target waiting duration can be a dynamic waiting time calculated based on the current occupancy duration and the effective duration threshold. For example, the target waiting duration can be determined based on the difference between the effective duration threshold and the current occupancy duration.

[0097] Optionally, after the version number processing system fails to acquire the project lock corresponding to the project identifier, it extracts the Tlock (lock acquisition timestamp) of the project lock from the shared storage component, calculates the difference between the Tlock and the current system time to determine the current holding time of the project lock, and then dynamically calculates the target waiting time by combining the pre-configured project lock effective duration threshold. After waiting for the target waiting time, the version information processing system re-initiates the request to acquire the project lock corresponding to the project identifier.

[0098] It is worth noting that, to ensure the uniqueness of version number generation in multi-task concurrent scenarios, this application introduces a mutual exclusion project lock in the sequence generation process. The validity of the project lock can be determined by the following condition: Let the current lock timestamp be T. lock The current system time is T. now The effective duration threshold of the lock is T. timeout The lock expiration condition is as follows:

[0099]

[0100] Here, `Expired` is a boolean value indicating the lock's expiration status, used to indicate whether the project lock has expired. If the project lock is valid (i.e., not expired), the version number generation operation is performed according to preset rules, such as auto-incrementing the version number. ; This indicates the current version number of the target project S under the generation cycle D; S is the unique index of the target project (corresponding to the project identifier); D is the index of the current generation cycle (for the date generation cycle identifier, such as the date in calendar days).

[0101] In one embodiment, the method for reusing software version information may further include: updating the status of the recycled version information when the recycled version information is successfully obtained; and using the recycled version information with the updated status as the target version information corresponding to the target component.

[0102] Optionally, when the version information processing system successfully retrieves the recycled version information of a target component under the target project—meaning that reusable software version information exists in the recycling pool associated with the target project—it indicates that there is no need to regenerate new software version information. The system then updates the recycled software version information to the usable software version information and uses it as the target version information for the target component. This method achieves the recycling of version information resources and alleviates resource waste caused by version information redundancy.

[0103] It is worth noting that the reuse of software version information can be achieved through the following operational logic: The version information processing system first acquires the project lock corresponding to the target project, and then attempts to obtain reusable version information from the recycling pool (version_pool) corresponding to the project identifier + current date dimension. The specific logic is as follows:

[0104]

[0105] Where V represents the final output target version information, which can be either reused recycled version information or newly generated version information; Vrecycled represents the recycled version information obtained from the recycling pool; Vnew represents the version information to be newly generated; if there is no available version information in the recycling pool (i.e., a new version needs to be generated), then Vnew is generated according to the following rules:

[0106]

[0107] Among them, BaseVersion is the basic prefix of the version information, which is a preset fixed string; It can be the version number of the target project in the current generation cycle (D), obtained by incrementing a counter, using the formula: ; This can be a counter corresponding to the project identifier and the current date dimension; D is the current date code, which can be in YYMMDD format; This indicates that Seq(project,D) will be formatted as a 4-character string; the final version information (Vrecycled or Vnew) will be updated to the status of "used". State(V) is the status field of version information V. Setting it to "used" indicates that the final version information is marked as "used" to avoid being reassigned. After the version information is determined and the status is updated, the version information processing system releases the project lock corresponding to the target project.

[0108] For example, this application implements state management of the entire lifecycle of version information through a state machine, and its state transition logic is defined through a state transition function, the specific expression of which is:

[0109]

[0110] Here, Statecurrent can represent the current state of the version information; Event can represent the operation event that triggers the state transition of the version information, such as the recycling event and the usage event; f can represent the state transition function, which is used to define the target state corresponding to the current state and the triggering event; and Statenext can represent the target state of the version information after the state transition.

[0111] Based on the aforementioned state transition function, the typical state transition rules for version information in this application include: when the current state of the version information is "used" and the triggering event is "recycle," the state transition is to "recycled," that is... When the current state of the version information is recycled and the triggering event is allocate, the state transitions to used. When the current state of the version information is "used" and the triggering event is "lock," the state transitions to "locked." The version sequence table (such as a hash table) maintains the information and status of all versions generated in the current generation cycle. The data structure of the version sequence table is as follows: , For version sequence list, it is a collection used to store and maintain version information and corresponding states, where Vi is the i-th version information and Statei is the state of the i-th version information.

[0112] In one embodiment, the method for reclaiming software version information may further include: receiving a request to reclaim historical version information of a target component under the target project; and using the historical version information as the reclaimed version information of the target component under the target project.

[0113] Among them, historical version information can be old version information of the target component that was once deployed or used, but is no longer in use due to software upgrades, rollback testing completion, or version obsolescence; recycling requests can be requests to reclaim idle historical version information.

[0114] Optionally, the version information processing system receives a request from the build system to reclaim idle historical version information of the target component at the target project level, updates the status of the historical version information to reclaimable, and includes it in the reclaim pool corresponding to the target project, making it reusable reclaimable version information of the target component under the target project.

[0115] It's worth noting that for version information that hasn't completed its usage process, a recycling operation can be performed on the version information, that is, the status of the version information can be updated to "recycled". Simultaneously, this version information is added to the recycling pool queue corresponding to the project identifier and the current generation cycle dimension. The specific operation logic is as follows: `enqueue(V)` is the enqueue operation for the queue. `enqueue` is the standard method for FIFO queues, adding version information V to the tail of the recycling pool queue to ensure that subsequent reuse follows the "first-recycle, first-allocate" order. The recycling pool queue is managed using First-In-First-Out (FIFO) logic. Its core function is to ensure that when subsequent version numbers are allocated, version information in the recycling pool is reused first according to the recycling time order, ensuring the orderly circulation of version resources.

[0116] For example, such as Figure 4 As shown, after receiving a version information generation request, this application executes a distributed lock acquisition operation. If the distributed lock acquisition is successful, it attempts to obtain reusable version information from the version information (such as version number) recycling pool, and determines whether reusable version information exists in the recycling pool. If reusable version information exists in the recycling pool, its status is directly marked as used, completing the version information allocation for the target object. If no reusable version information exists in the recycling pool, new version information is generated based on preset version information generation rules, and its status is marked as used. If the distributed lock acquisition fails, it determines whether the number of retries for lock acquisition has reached a preset threshold. If the number of retries has exceeded the limit, a system busy error message is returned. If the number of retries has not exceeded the limit, the distributed lock acquisition operation is re-executed after a random duration, and the above lock acquisition and subsequent determination logic is executed cyclically.

[0117] In this embodiment, by prioritizing the acquisition of recycled version information, idle version information that has been generated but not actually used under the target project can be redistributed to the target component, which alleviates resource redundancy and coding waste caused by version information generation, improves the overall utilization rate of version information resources, and reduces the frequency of new version information generation.

[0118] To more comprehensively demonstrate this solution, this embodiment presents an alternative method for vehicle control, such as... Figure 5 As shown, it includes the following steps:

[0119] S501, Receive a version information generation request for a target component in the target device; The version information generation request carries the project identifier of the target project to which the target component belongs;

[0120] S502, Obtain the project lock corresponding to the project identifier;

[0121] S503, if the project lock is successfully acquired, retrieve the recycled version information of the target component under the target project;

[0122] S504, In the event that the version information retrieval fails, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle;

[0123] S505, obtain the software description information associated with the project identifier;

[0124] S506, according to the version information data structure, combine the current sequence number of the counter, the current generation cycle and the software description information to obtain the target version information corresponding to the target component;

[0125] S507 releases the project lock after generating the target version information.

[0126] The specific process described above can be found in the description of the above method embodiments, and its implementation principle and technical effect are similar, so they will not be repeated here.

[0127] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0128] Based on the same inventive concept, this application also provides a software version information management device for implementing the software version information management method described above. The solution provided by this device is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more software version information management device embodiments provided below can be found in the limitations of the software version information management method described above, and will not be repeated here.

[0129] In one exemplary embodiment, such as Figure 6As shown, a software version information management device is provided, including: a receiving module 61, an acquiring module 62, an updating module 63, a generating module 64, and a management module 63, wherein:

[0130] The receiving module 61 is used to receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project to which the target component belongs;

[0131] Module 62 is used to obtain the project lock corresponding to the project identifier;

[0132] Update module 63 is used to update the current sequence number of the counter corresponding to the project identifier in the current generation cycle when the project lock is successfully acquired; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0133] The generation module 64 is used to generate target version information corresponding to the target component based on the current serial number of the counter, the current generation cycle, and the project identifier;

[0134] Management module 65 is used to release the project lock after the target version information is generated.

[0135] In one embodiment, the update module 63 is further configured to:

[0136] If the project lock is successfully acquired, retrieve the recycled version information of the target component under the target project;

[0137] If the version information retrieval fails, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle.

[0138] In one embodiment, the update module 63 is further configured to:

[0139] If the version information is successfully retrieved, update the status of the version information to reflect the changes.

[0140] The updated version information is used as the target version information for the target component.

[0141] In one embodiment, the update module 63 is further configured to:

[0142] Receive requests to reclaim historical version information for a target component under the target project;

[0143] Historical version information is used as the recycled version information for the target component under the target project.

[0144] In one embodiment, the acquisition module 62 is further configured to:

[0145] If acquiring the project lock fails, determine the current duration of the project lock holding;

[0146] Determine the target waiting time based on the current occupancy time and the effective duration threshold of the project lock;

[0147] After waiting for the target's specified waiting time, reacquire the project lock.

[0148] In one embodiment, the acquisition module 62 is further configured to:

[0149] Obtain the software description information associated with the project identifier;

[0150] Based on the version information data structure, the target version information corresponding to the target component is obtained by combining the current sequence number of the counter, the current generation cycle, and the software description information.

[0151] Each module in the aforementioned software version information management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0152] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a software version information management method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0153] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0154] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0155] Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project to which the target component belongs;

[0156] Obtain the project lock corresponding to the project identifier;

[0157] If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0158] Based on the current serial number, current generation cycle, and project identifier of the counter, generate the target version information corresponding to the target component;

[0159] After generating the target version information, release the project lock.

[0160] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0161] If the project lock is successfully acquired, retrieve the recycled version information of the target component under the target project;

[0162] If version information retrieval fails, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle.

[0163] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0164] If the version information is successfully retrieved, update the status of the version information to reflect the changes.

[0165] The updated version information is used as the target version information for the target component.

[0166] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0167] Receive requests to reclaim historical version information for a target component under the target project;

[0168] Historical version information is used as the recycled version information for the target component under the target project.

[0169] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0170] If acquiring the project lock fails, determine the current duration of the project lock holding;

[0171] Determine the target waiting time based on the current occupancy time and the effective duration threshold of the project lock;

[0172] After waiting for the target's specified waiting time, reacquire the project lock.

[0173] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0174] Obtain the software description information associated with the project identifier;

[0175] Based on the version information data structure, the target version information corresponding to the target component is obtained by combining the current sequence number of the counter, the current generation cycle, and the software description information.

[0176] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0177] Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project to which the target component belongs;

[0178] Obtain the project lock corresponding to the project identifier;

[0179] If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0180] Based on the current serial number, current generation cycle, and project identifier of the counter, generate the target version information corresponding to the target component;

[0181] After generating the target version information, release the project lock.

[0182] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0183] If the project lock is successfully acquired, retrieve the recycled version information of the target component under the target project;

[0184] If version information retrieval fails, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle.

[0185] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0186] If the version information is successfully retrieved, update the status of the version information to reflect the changes.

[0187] The updated version information is used as the target version information for the target component.

[0188] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0189] Receive requests to reclaim historical version information for a target component under the target project;

[0190] Historical version information is used as the recycled version information for the target component under the target project.

[0191] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0192] If acquiring the project lock fails, determine the current duration of the project lock holding;

[0193] Determine the target waiting time based on the current occupancy time and the effective duration threshold of the project lock;

[0194] After waiting for the target's specified waiting time, reacquire the project lock.

[0195] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0196] Obtain the software description information associated with the project identifier;

[0197] Based on the version information data structure, the target version information corresponding to the target component is obtained by combining the current sequence number of the counter, the current generation cycle, and the software description information.

[0198] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0199] Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project to which the target component belongs;

[0200] Obtain the project lock corresponding to the project identifier;

[0201] If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle.

[0202] Based on the current serial number, current generation cycle, and project identifier of the counter, generate the target version information corresponding to the target component;

[0203] After generating the target version information, release the project lock.

[0204] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0205] If the project lock is successfully acquired, retrieve the recycled version information of the target component under the target project;

[0206] If the version information retrieval fails, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle.

[0207] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0208] If the version information is successfully retrieved, update the status of the version information to reflect the changes.

[0209] The updated version information is used as the target version information for the target component.

[0210] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0211] Receive requests to reclaim historical version information for a target component under the target project;

[0212] Historical version information is used as the recycled version information for the target component under the target project.

[0213] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0214] If acquiring the project lock fails, determine the current duration of the project lock holding;

[0215] Determine the target waiting time based on the current occupancy time and the effective duration threshold of the project lock;

[0216] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0217] Obtain the software description information associated with the project identifier;

[0218] Based on the version information data structure, the target version information corresponding to the target component is obtained by combining the current sequence number of the counter, the current generation cycle, and the software description information.

[0219] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0220] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0221] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0222] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A software version information management method, characterized in that, The method includes: Receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project to which the target component belongs; Obtain the project lock corresponding to the project identifier; If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle. Based on the current serial number of the counter, the current generation cycle, and the project identifier, generate the target version information corresponding to the target component; After generating the target version information, release the project lock.

2. The method according to claim 1, characterized in that, If the project lock is successfully acquired, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle, including: If the project lock is successfully acquired, obtain the recycled version information of the target component under the target project; If the acquisition of the recycled version information fails, update the current sequence number of the counter corresponding to the project identifier in the current generation cycle.

3. The method according to claim 2, characterized in that, The method further includes: If the reclaimed version information is successfully obtained, update the status of the reclaimed version information; The updated version information is used as the target version information corresponding to the target component.

4. The method according to claim 2, characterized in that, The method further includes: Receive a request to reclaim historical version information for the target component under the target project; The historical version information is used as the recycled version information of the target component under the target project.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: If acquiring the project lock fails, determine the current holding time of the project lock; The target waiting time is determined based on the current occupancy time and the effective duration threshold of the project lock; After waiting for the target's specified waiting time, reacquire the project lock.

6. The method according to any one of claims 1-4, characterized in that, Based on the current sequence number of the counter, the current generation cycle, and the project identifier, generate the target version information corresponding to the target component, including: Obtain the software description information associated with the project identifier; Based on the version information data structure, the current sequence number of the counter, the current generation cycle, and the software description information are combined to obtain the target version information corresponding to the target component.

7. A software version information management device, characterized in that, The device includes: The receiving module is used to receive a version information generation request for a target component in the target device; the version information generation request carries the project identifier of the target project. The acquisition module is used to acquire the project lock corresponding to the project identifier; The update module is used to update the current sequence number of the counter corresponding to the project identifier in the current generation cycle when the project lock is successfully acquired; the counter is used to record the number of times the project identifier generates new version information in the current generation cycle. The generation module is used to generate target version information corresponding to the target component based on the current sequence number of the counter, the current generation cycle, and the project identifier; The management module is used to release the project lock after the target version information is generated.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

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

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

Images