CN114416430A - Software version management method, system, device and medium - Google Patents
Software version management method, system, device and medium Download PDFInfo
- Publication number
- CN114416430A CN114416430A CN202210093452.3A CN202210093452A CN114416430A CN 114416430 A CN114416430 A CN 114416430A CN 202210093452 A CN202210093452 A CN 202210093452A CN 114416430 A CN114416430 A CN 114416430A
- Authority
- CN
- China
- Prior art keywords
- component
- version
- software
- version number
- main
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/62—Uninstallation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a management method, a system, equipment and a medium of software versions, wherein the management method comprises the following steps: acquiring version information of the component; the component version information includes a version number of each component in a current state; and generating main version information according to the component version information so that at least one client side carries out software version change according to the main version information. According to the invention, through the unified component version numbering rule, the main version numbering rule and the software version changing mechanism, the error rate of software version upgrading is reduced, and the problem of software version management chaos is solved; when the component type is complex and the software version upgrading fails, the source code is quickly searched and corrected by backing the main version number, and the software version upgrading efficiency is improved.
Description
Technical Field
The present invention relates to the field of software technologies, and in particular, to a method, a system, a device, and a medium for managing software versions.
Background
The terminal equipment in the power industry generally uses a wireless private network for data acquisition and electrical equipment control. In order to meet the continuous development of the power system, the software version in the terminal equipment needs to be updated frequently. The SCADA (Supervisory Control And Data Acquisition, Supervisory Control system) system of each wind farm And each component in the system have version numbers, And the components have customization problems, so that a single component can independently upgrade the version, And a plurality of current systems do not have standardized management version numbers, so that various version numbers And numbering rules are different greatly. In fact, software version updates are often in component units, and in most cases, the upgrade of a software version is only the upgrade of a partial component.
When a client of an existing wind power plant with an SCADA system carries out single component upgrading, the version number of an upgrading component and the version number of whole software are difficult to control to correspond to each other. Firstly, when the number of components to be upgraded in a client with an SCADA system in each wind farm is large, the management of the version of the whole software is disturbed; secondly, if the software upgrading fails, the software cannot be timely backed off according to the version number of the system, and the version number corresponding to each component is difficult to be quickly determined, so that the corresponding source code cannot be quickly found to solve the problem.
Disclosure of Invention
The invention provides a management method, a system, equipment and a medium for software version upgrading, aiming at overcoming the defects of the prior art that the number of components is large, the software version upgrading is easy to make mistakes and the efficiency is low, and the software version management is disordered.
The invention solves the technical problems through the following technical scheme:
in a first aspect, the present invention provides a method for managing software versions, which is applied to a server, and the method for managing software versions includes:
acquiring version information of the component; the component version information comprises a version number and a source code of each component in the current state;
generating main version information according to the component version information so that at least one client side can change the software version according to the main version information; the software version change comprises a software upgrade and a software downgrade;
the main version information comprises a main version number, the main version number changes according to the change of the version number of any component, and any main version number corresponds to the uniquely determined component version information.
Preferably, the management method further comprises:
storing the component version information and the master version information in the same database; the component version information corresponds to the master version information.
Preferably, when the database is used for software degradation of a wind farm SCADA system, the management method further comprises:
receiving degradation rollback information; the downgrade rollback information includes a major version number of a rollback and a major version number of an upgrade exception;
searching the first component version information corresponding to the returned main version number from the database;
and searching second component version information corresponding to the abnormal upgrading main version number from the database.
Preferably, the management method further comprises:
comparing the first component version information and the second component version information to determine a target component;
and modifying the target source code corresponding to the target assembly so that the client side performs software version change according to the modified target source code.
Preferably, when the database is used for software upgrade of a wind farm SCADA system, the management method further comprises:
receiving upgrading request information; the upgrade request information comprises a main version number before upgrading;
and comparing the main version number before upgrading with the main version number in the current state stored in the database, and if the main version number before upgrading is different from the main version number in the current state, acquiring and sending the main version information corresponding to the main version number in the current state.
In a second aspect, the present invention provides a software version management system, including:
the acquisition module is used for acquiring the version information of the component; the component version information includes a version number of each component in a current state;
the generating module is used for generating main version information according to the component version information so that at least one client side can change the software version according to the main version information; the software version change comprises a software upgrade and a software downgrade;
the main version information comprises a main version number, the main version number changes according to the change of the version number of any component, and any main version number corresponds to the uniquely determined component version information.
Preferably, the management system further comprises:
the storage module is used for storing the component version information and the main version information in the same database; the component version information corresponds to the master version information.
Preferably, when the database is used for software degradation of a wind farm SCADA system, the management system further comprises:
a first receiving module, configured to receive fallback information; the downgrade rollback information includes a major version number of a rollback and a major version number of an upgrade exception;
the first searching module is used for searching the first component version information corresponding to the returned main version number from the database;
and the second searching module is used for searching the second component version information corresponding to the abnormal upgrading main version number from the database.
Preferably, the management system further comprises:
a first comparison module for comparing the first component version information and the second component version information to determine a target component;
and the correction module is used for correcting the target source code corresponding to the target component so as to enable the client to update the software version according to the corrected target source code.
Preferably, when the database is used for software upgrade of a wind farm SCADA system, the management system further comprises:
the second receiving module is used for receiving the upgrading request information; the upgrade request information comprises a main version number before upgrading;
and the second comparison module is used for comparing the main version number before upgrading with the main version number in the current state stored in the database, and if the main version number before upgrading is different from the main version number in the current state, acquiring and sending the main version information corresponding to the main version number in the current state.
In a third aspect, the present invention provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the processor implements the method for managing software versions as described in the first aspect.
In a fourth aspect, the present invention also provides a computer-readable storage medium, in which a computer program is stored, which, when executed by a processor, implements the method for managing software versions as set forth in the first aspect.
The positive progress effects of the invention are as follows: a method, a system, a device and a medium for managing software version are provided, which generate major version information including major version number through component version information, so that a client can automatically change the software version according to the major version information. According to the invention, through the unified component version numbering rule, the main version numbering rule and the software version changing mechanism, the error rate of software version upgrading is reduced, and the problem of software version management chaos is solved; when the component type is complex and the software version upgrading fails, the source code is quickly searched and corrected by backing the main version number, and the software version upgrading efficiency is improved.
Drawings
Fig. 1 is a first flowchart of a software version management method according to embodiment 1 of the present invention.
Fig. 2 is a second flowchart of the software version management method according to embodiment 1 of the present invention.
Fig. 3 is a third flowchart of the software version management method according to embodiment 1 of the present invention.
Fig. 4 is a schematic block diagram of a software version management system according to embodiment 2 of the present invention.
Fig. 5 is a schematic diagram of a hardware structure of an electronic device according to embodiment 3 of the present invention.
Detailed Description
The invention is further illustrated by the following examples, which are not intended to limit the scope of the invention.
Example 1
As shown in fig. 1, the present embodiment provides a software version management method, applied to a server, where the management method includes the following steps:
s1, acquiring version information of the component; the component version information includes a version number of each component in the current state.
S2, generating master version information according to the component version information, so that at least one client side can change the software version according to the master version information; the software version change includes a software upgrade and a software downgrade.
The main version information comprises a main version number, the main version number changes according to the change of the version number of any component, and any main version number corresponds to the uniquely determined component version information.
S3, storing the component version information and the main version information in the same database; the component version information corresponds to the master version information.
With respect to the step S1, the software version management method in this embodiment may be implemented by a server. A server managing clients of multiple wind farms may obtain component version information from a SCADA system facilitator each time. Illustratively, the component version information includes three different components, respectively a source code and version number of the first component, a source code and version number of the second component, and a source code and version number of the third component.
In step S2, the master version number of the SCADA system software in the current state is generated according to the version number of the first component, the version number of the second component, and the version number of the third component. For example, the source code corresponding to the 1.0 version number of the first component is a first source code, the source code corresponding to the 1.0 version number of the second component is a second source code, and the source code corresponding to the 1.0 version number of the third component is a third source code. And generating the V1.0 software version upgrading package through computer compiling processing according to the first source code, the second source code and the third source code. Second, the major version number corresponds to the software upgrade package, the major version number V1.0 may correspond to the software upgrade package V1.0, and the major version number V1.1 may correspond to the software upgrade package V1.1.
For example, if the version number of the first component in the current state is 1.0, the version number of the second component is 1.0, and the version number of the third component is 1.0, the major version number of the SCADA system software in the current state is generated to be V1.0. And if the version number of the first component in the current state is 1.1, the version number of the second component is 1.0 and the version number of the third component is 1.0, generating a major version number of the SCADA system software in the current state to be V1.1. And if the version number of the first component in the current state is 1.1, the version number of the second component is 1.1 and the version number of the third component is 1.0, generating a main version number of the SCADA system software in the current state to be V1.2.
For the step S3, the component version information and the master version information are stored in the same database, and the database is further used for storing the current latest master version number of the SCADA system of each client of the wind farm and the current latest version number of each component.
In a possible implementation scheme, as shown in fig. 2, the management method further includes the following steps:
s41, receiving degradation rollback information; the destage rollback information includes a major version number to which to rollback and a major version number to which to promote exceptions.
And S51, searching the first component version information corresponding to the returned main version number from the database.
And S61, searching second component version information corresponding to the abnormal main version number of the upgrade from the database.
And S71, comparing the first component version information with the second component version information to determine the target component.
And S81, correcting the target source code corresponding to the target assembly so that the client side can change the software version according to the corrected target source code.
For the steps S41-S71, when a software upgrade exception occurs during the process of performing software upgrade by the client of the wind farm according to the obtained latest master version information, the server receives downgrade rollback information sent by the SCADA client of at least one wind farm. The downgrade rollback information may include a major version number to which rollback is required and a major version number where a upgrade exception exists.
And searching first component version information corresponding to the major version number needing to be returned from the database, and searching second component version information corresponding to the major version number with abnormal upgrade from the database. And further judging whether the version number of each component in the first component version information and the version number of the same component in the second component version information are different, if so, indicating that the component has a version number change, and finally checking a source code corresponding to the component with the version number change, namely, checking whether the source code of the component in the second component version information is abnormal, and if so, judging the component as the target component with the abnormality.
For step S81, the server may modify the source code of the target component, generate a modified source code and a corresponding modified software upgrade package, and send the software upgrade package to at least one SCADA client of the wind farm, so that the client performs software upgrade again according to the modified target source code. The method is beneficial to timely finding out the abnormal target assembly in the software upgrading package, and the problem that the source code is quickly found due to the failure of software upgrading is solved.
In a possible implementation scheme, as shown in fig. 3, the management method further includes the following steps:
s42, receiving upgrading request information; the upgrade request information includes a major version number before upgrade.
And S52, comparing the master version number before upgrading with the master version number in the current state stored in the database, and if the master version number before upgrading is different from the master version number in the current state, acquiring and sending master version information corresponding to the master version number in the current state.
With respect to the step S42, the server sends the software upgrade prompt information to one or more clients each time, so as to receive the upgrade request information sent by the client of the SCADA of at least one wind farm. Or receiving upgrading request information automatically initiated by users of one or more clients of the wind power plant SCADA in real time.
With respect to the above step S52, the major version number before the upgrade is compared with the major version number in the current state stored in the database to determine whether the latest version exists. And if the major version number in the current state stored in the database is greater than the major version number before upgrading, sending the software upgrading package corresponding to the major version number in the current state to the client. If the major version number of the current state stored in the database is not greater than the major version number before upgrading, the prompt information which does not need to be upgraded can be fed back to the client.
It should be noted that, after at least one client having the SCADA system in the wind farm completes one software upgrade, the server periodically and automatically obtains the upgrade result, and stores the upgrade result in the database in step S3, which is helpful for system version management of the SCADA system in the wind farm.
The embodiment provides a management method of a software version, which is used for acquiring version information of a component; the component version information comprises a version number and a source code of any component in the current state; and generating main version information according to the version number and the source code of any component in the current state, so that at least one client side carries out software version change according to the main version information. According to the invention, through the unified component version numbering rule, the main version numbering rule and the software version changing mechanism, the error rate of software version upgrading is reduced, and the problem of software version management chaos is solved; when the component type is complex and the software version upgrading fails, the source code is quickly searched and corrected by backing the main version number, and the software version upgrading efficiency is improved.
Example 2
As shown in fig. 4, the present embodiment provides a software version management system, which includes: the device comprises an acquisition module 110, a generation module 120 and a storage module 130.
An obtaining module 110, configured to obtain component version information; the component version information includes a version number of each component in the current state.
A generating module 120, configured to generate master version information according to the component version information, so that at least one client performs software version change according to the master version information; the software version change includes a software upgrade and a software downgrade.
The main version information comprises a main version number, the main version number changes according to the change of the version number of any component, and any main version number corresponds to the uniquely determined component version information.
A storage module 130, configured to store the component version information and the master version information in the same database; the component version information corresponds to the master version information.
The management method of the software version in this embodiment may be implemented by a server. The acquisition module 110 may acquire component version information from a SCADA system facilitator each time. Illustratively, the component version information includes three different components and source code corresponding to each component, respectively a source code and a version number of the first component, a source code and a version number of the second component, and a source code and a version number of the third component.
The generating module 120 generates a major version number and a software version upgrade package of the SCADA system software in the current state according to the source code and the version number of the first component, the source code and the version number of the second component, and the source code and the version number of the third component. The major version number corresponds to the software upgrade package, for example, the source code corresponding to the 1.0 version number of the first component is a first source code, the source code corresponding to the 1.0 version number of the second component is a second source code, and the source code corresponding to the 1.0 version number of the third component is a third source code. And generating the V1.0 software version upgrading package through computer compiling processing according to the first source code, the second source code and the third source code. Second, the major version number corresponds to the software upgrade package, the major version number V1.0 may correspond to the software upgrade package V1.0, and the major version number V1.1 may correspond to the software upgrade package V1.1.
For example, if the version number of the first component in the current state is 1.0, the version number of the second component is 1.0, and the version number of the third component is 1.0, the generated major version number of the SCADA system software in the current state is V1.0; if the version number of the first component in the current state is 1.1, the version number of the second component is 1.0 and the version number of the third component is 1.0, the generated major version number of the SCADA system software in the current state is V1.1; and if the version number of the first component in the current state is 1.1, the version number of the second component is 1.1 and the version number of the third component is 1.0, generating a main version number of the SCADA system software in the current state to be V1.2.
The storage module 130 stores the component version information and the master version information in the same database, which is also used for storing the current latest master version number of the SCADA system of each client of the wind farm and the current latest version number of each component.
In a possible implementation scheme, as shown in fig. 4, the management system further includes: a first receiving module 141, a first lookup module 151, a second lookup module 161, a first comparing module 171, and a modifying module 181.
A first receiving module 141, configured to receive fallback information; downgrade rollback information includes a major version number to which to rollback and a major version number to which to raise exceptions.
The first searching module 151 is configured to search the database for the first component version information corresponding to the returned major version number.
The second searching module 161 is configured to search, from the database, second component version information corresponding to the upgrade exception primary version number.
A first comparing module 171, configured to compare the first component version information and the second component version information to determine the target component.
And the modification module 181 is configured to modify the target source code corresponding to the target component, so that the client changes according to the modified target source code software version.
When a software upgrading process is performed by the client of the wind farm according to the obtained latest master version information, and a software upgrading exception occurs, the first receiving module 141 receives degradation rollback information sent by at least one SCADA client of the wind farm. The downgrade rollback information may include a major version number to which rollback is required and a major version number where a upgrade exception exists.
The first searching module 151 searches for first component version information corresponding to a major version number that needs to be backed up from the database, and the second searching module 161 searches for second component version information corresponding to a major version number that is abnormally upgraded from the database. The first comparing module 171 further determines whether the version number of each component in the first component version information and the version number of each component in the second component version information are different, if so, it indicates that the component has a version number change, and finally checks the source code corresponding to the component having the version number change. That is, whether the source code of the component in the second component version information has an error is checked, and if the source code of the component in the second component version information has an error, the component is determined to be a target component which has a source code abnormality and needs to be version-maintained.
The modification module 181 may modify the source code of the target component, generate a modified source code and a corresponding modified software upgrade package, and send the software upgrade package to at least one SCADA client of the wind farm, so that the client performs software upgrade again according to the modified target source code. The method is beneficial to timely finding out the abnormal target assembly in the software upgrading package, and the problem that the source code is quickly found due to the failure of software upgrading is solved.
In a possible implementation scheme, as shown in fig. 4, the management system further includes: a second receiving module 142 and a second comparing module 152.
A second receiving module 142, configured to receive upgrade request information; the upgrade request information includes a major version number before upgrade.
The second comparing module 152 is configured to compare the major version number before the upgrade with the major version number in the current state stored in the database, and if the major version number before the upgrade is different from the major version number in the current state, obtain and send major version information corresponding to the major version number in the current state.
The second receiving module 142 may send the software upgrade prompt information to one or more clients each period of time, so as to receive the upgrade request information sent by the clients of the SCADA of at least one wind farm. Or receiving upgrading request information automatically initiated by users of one or more clients of the wind power plant SCADA in real time.
The second comparison module 152 compares the major version number before upgrade with the major version number in the current state stored in the database to determine whether the latest version exists. And if the major version number in the current state stored in the database is greater than the major version number before upgrading, sending the software upgrading package corresponding to the major version number in the current state to the client. If the major version number of the current state stored in the database is not greater than the major version number before upgrading, the prompt information which does not need to be upgraded can be fed back to the client.
It should be noted that, after at least one client having the SCADA system in the wind farm completes one software upgrade, the server periodically and automatically obtains the upgrade result, and stores the upgrade result in the database in step S3, which is helpful for system version management of the SCADA system in the wind farm.
The embodiment provides a management system of a software version, an obtaining module obtains version information of a component; the component version information comprises a version number and a source code of any component in the current state; and the generation module generates main version information according to the version number and the source code of any component in the current state, so that at least one client side carries out software version change according to the main version information. According to the invention, through the unified component version numbering rule, the main version numbering rule and the software version changing mechanism, the error rate of software version upgrading is reduced, and the problem of software version management chaos is solved; when the component type is complex and the software version upgrading fails, the source code is quickly searched and corrected by backing the main version number, and the software version upgrading efficiency is improved.
Example 3
Fig. 5 is a schematic structural diagram of an electronic device provided in this embodiment. The intelligent helmet comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, and the processor implements the method for managing the software version of embodiment 1 when executing the program, and the electronic device 60 shown in fig. 5 is only an example and should not bring any limitation to the functions and the scope of the embodiments of the present invention.
The electronic device 60 may be embodied in the form of a general purpose computing device, which may be a server device, for example. The components of the electronic device 60 may include, but are not limited to: the at least one processor 61, the at least one memory 62, and a bus 63 connecting the various system components (including the memory 62 and the processor 61).
The bus 63 includes a data bus, an address bus, and a control bus.
The memory 62 may include volatile memory, such as Random Access Memory (RAM)621 and/or cache memory 622, and may further include Read Only Memory (ROM) 623.
The memory 62 may also include a program/utility 625 having a set (at least one) of program modules 624, such program modules 624 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
The processor 61 executes various functional applications and data processing, such as a management method of software versions of embodiment 1 of the present invention, by running the computer program stored in the memory 62.
The electronic device 60 may also communicate with one or more external devices 64 (e.g., keyboard, pointing device, etc.). Such communication may be through an input/output (I/O) interface 65. Also, the model-generating electronic device 60 may also communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet) via a network adapter 66. As shown, network adapter 66 communicates with the other modules of model-generating electronic device 60 via bus 63. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the model-generating electronic device 60, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems, etc.
It should be noted that although in the above detailed description several units/modules or sub-units/modules of the electronic device are mentioned, such a division is merely exemplary and not mandatory. Indeed, the features and functionality of two or more of the units/modules described above may be embodied in one unit/module according to embodiments of the invention. Conversely, the features and functions of one unit/module described above may be further divided into embodiments by a plurality of units/modules.
Example 4
The present embodiment provides a computer-readable storage medium on which a computer program is stored, which when executed by a processor, implements the management method of the software version of embodiment 1.
More specific examples, among others, that the readable storage medium may employ may include, but are not limited to: a portable disk, a hard disk, random access memory, read only memory, erasable programmable read only memory, optical storage device, magnetic storage device, or any suitable combination of the foregoing.
In a possible implementation, the invention can also be implemented in the form of a program product comprising program code for causing a terminal device to execute a management method implementing the software version of embodiment 1 when said program product is run on said terminal device.
Where program code for carrying out the invention is written in any combination of one or more programming languages, the program code may be executed entirely on the user device, partly on the user device, as a stand-alone software package, partly on the user device and partly on a remote device or entirely on the remote device.
While specific embodiments of the invention have been described above, it will be appreciated by those skilled in the art that this is by way of example only, and that the scope of the invention is defined by the appended claims. Various changes and modifications to these embodiments may be made by those skilled in the art without departing from the spirit and scope of the invention, and these changes and modifications are within the scope of the invention.
Claims (12)
1. A management method of software versions is applied to a server, and the management method comprises the following steps:
acquiring version information of the component; the component version information includes a version number of each component in a current state;
generating main version information according to the component version information so that at least one client side can change the software version according to the main version information; the software version change comprises a software upgrade and a software downgrade;
the main version information comprises a main version number, the main version number changes according to the change of the version number of any component, and any main version number corresponds to the uniquely determined component version information.
2. The method for managing software versions according to claim 1, further comprising:
storing the component version information and the master version information in the same database; the component version information corresponds to the master version information.
3. A management method of software versions according to claim 2, characterized in that when said database is used for software downgrading of a wind farm SCADA system, it further comprises:
receiving degradation rollback information; the downgrade rollback information includes a major version number of a rollback and a major version number of an upgrade exception;
searching the first component version information corresponding to the returned main version number from the database;
and searching second component version information corresponding to the abnormal upgrading main version number from the database.
4. A method of managing software versions according to claim 3, further comprising:
comparing the first component version information and the second component version information to determine a target component;
and modifying the target source code corresponding to the target assembly so that the client side performs software version change according to the modified target source code.
5. A management method of software versions according to claim 2, characterized in that when said database is used for software upgrading of a wind farm SCADA system, it further comprises:
receiving upgrading request information; the upgrade request information comprises a main version number before upgrading;
and comparing the main version number before upgrading with the main version number in the current state stored in the database, and if the main version number before upgrading is different from the main version number in the current state, acquiring and sending the main version information corresponding to the main version number in the current state.
6. A management system for software versions, the management system comprising:
the acquisition module is used for acquiring the version information of the component; the component version information includes a version number of each component in a current state;
the generating module is used for generating main version information according to the component version information so that at least one client side can change the software version according to the main version information; the software version change comprises a software upgrade and a software downgrade;
the main version information comprises a main version number, the main version number changes according to the change of the version number of any component, and any main version number corresponds to the uniquely determined component version information.
7. The software release management system of claim 6, wherein the management system further comprises:
the storage module is used for storing the component version information and the main version information in the same database; the component version information corresponds to the master version information.
8. Management system of software versions according to claim 7, characterized in that when said database is used for software downgrading of wind farm SCADA systems, it further comprises:
a first receiving module, configured to receive fallback information; the downgrade rollback information includes a major version number of a rollback and a major version number of an upgrade exception;
the first searching module is used for searching the first component version information corresponding to the returned main version number from the database;
and the second searching module is used for searching the second component version information corresponding to the abnormal upgrading main version number from the database.
9. The software release management system of claim 8, wherein the management system further comprises:
a first comparison module for comparing the first component version information and the second component version information to determine a target component;
and the correction module is used for correcting the target source code corresponding to the target component so as to enable the client to update the software version according to the corrected target source code.
10. Management system of software versions according to claim 7, characterized in that when said database is used for software upgrading of wind farm SCADA systems, said management system further comprises:
the second receiving module is used for receiving the upgrading request information; the upgrade request information comprises a main version number before upgrading;
and the second comparison module is used for comparing the main version number before upgrading with the main version number in the current state stored in the database, and if the main version number before upgrading is different from the main version number in the current state, acquiring and sending the main version information corresponding to the main version number in the current state.
11. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the method of managing software versions according to any one of claims 1 to 5 when executing the computer program.
12. A computer-readable storage medium, in which a computer program is stored, which, when being executed by a processor, implements a method of managing software versions according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210093452.3A CN114416430A (en) | 2022-01-26 | 2022-01-26 | Software version management method, system, device and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210093452.3A CN114416430A (en) | 2022-01-26 | 2022-01-26 | Software version management method, system, device and medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114416430A true CN114416430A (en) | 2022-04-29 |
Family
ID=81277549
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210093452.3A Pending CN114416430A (en) | 2022-01-26 | 2022-01-26 | Software version management method, system, device and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114416430A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114816393A (en) * | 2022-05-18 | 2022-07-29 | 北京百度网讯科技有限公司 | Information generation method, device, equipment and storage medium |
-
2022
- 2022-01-26 CN CN202210093452.3A patent/CN114416430A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114816393A (en) * | 2022-05-18 | 2022-07-29 | 北京百度网讯科技有限公司 | Information generation method, device, equipment and storage medium |
| CN114816393B (en) * | 2022-05-18 | 2023-12-19 | 北京百度网讯科技有限公司 | Information generation method, device, equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8291403B2 (en) | Install-unit upgrade using dynamic configuration data manipulation and merging | |
| US20140237463A1 (en) | Dynamically generate and execute a context-specific patch installation procedure on a computing system | |
| CN111158715B (en) | Gray release control method and system | |
| US11544326B2 (en) | Maintaining character set compatibility in database systems | |
| CN110555150B (en) | Data monitoring method, device, equipment and storage medium | |
| US20200341955A1 (en) | Prediction and repair of database fragmentation | |
| US20200026692A1 (en) | System and method for batch database modification | |
| CN112559140B (en) | Transaction control method, system, equipment and storage medium for data consistency | |
| US20240070026A1 (en) | Method For Remote Upgrade and Rollback of Unmanned Aerial Vehicle (UAV) Software | |
| CN111651304B (en) | Software recovery method and device based on double-core intelligent ammeter and computer equipment | |
| CN109522043B (en) | Method and device for managing configuration data and storage medium | |
| CN114416430A (en) | Software version management method, system, device and medium | |
| CN113065139A (en) | Alarm access method and system, electronic device and medium | |
| CN112486517B (en) | Application program installation method and system, electronic equipment and storage medium | |
| CN112256277A (en) | Software compiling method, system, electronic device and storage medium | |
| CN114047999A (en) | Page configuration method, system, electronic equipment and storage medium | |
| CN114047976A (en) | Plug-in loading method and device, electronic equipment and storage medium | |
| CN111930720A (en) | Data tilt processing method, system, electronic device and medium | |
| CN114610350A (en) | Method and device for updating query system, electronic equipment and storage medium | |
| CN113626423B (en) | Log management method, device and system of business database | |
| US11176024B1 (en) | Software patch application and testing optimization | |
| CN113946348A (en) | Terminal software function adapting method, system, electronic equipment and storage medium | |
| CN109254899B (en) | Server monitoring method and device | |
| CN114970476A (en) | Data processing method, system, electronic device and storage medium | |
| CN113064799A (en) | Client monitoring method, device, system, medium and computing equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |