Version matching method, electronic device, and storage medium

Abstract

This application provides a version matching method, an electronic device, and a storage medium. The method includes: acquiring development environment version information and reference environment version information; matching the development environment version information with the reference environment version information; determining target version information from the reference environment version information, so that the runtime environment configured with the target version information has compatibility with running the lightweight program corresponding to the development environment version information. Based on the version of the development environment used by the developers, a runtime environment version compatible with the development environment version is determined through version matching. The local device configured according to the runtime environment version can directly run the lightweight program. Developers do not need to consider compatibility issues that may exist during the operation of the lightweight program, and can flexibly choose the development environment according to their personal habits, reducing the adaptation cost to changes in the development environment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to version matching methods, electronic devices, and storage media. Background Technology

[0002] With the rapid development of the mobile internet, lightweight applications, as a form of lightweight application, are widely used due to their characteristics of being installation-free and ready to use immediately. After the R&D department completes the development of a lightweight application based on the development environment, when users use the lightweight application on their local devices (such as mobile phones), the local device also needs to have an environment that supports the operation of the lightweight application. In other words, the local device's operating environment needs to be compatible with the development environment of the lightweight application to ensure the normal operation of the lightweight application.

[0003] In related technologies, developers face high costs in adapting to changes in the development environment, and lightweight programs developed based on specific development environments have limited compatibility with the actual operating environment of local devices. Summary of the Invention

[0004] This application provides a version matching method, an electronic device, and a storage medium to solve the problems in related technologies, such as high adaptation costs for developers to changes in development environments and limited compatibility of lightweight programs developed based on specific development environments in actual operating environments. Developers can flexibly choose development environments, and lightweight programs developed based on different development environments are compatible in various possible actual operating environments and can automatically run on various local devices.

[0005] In a first aspect, embodiments of this application provide a version matching method, the method comprising:

[0006] Obtain development environment version information and reference environment version information; The development environment version information is matched with the reference environment version information, and the target version information is determined from the reference environment version information so that the runtime environment configured with the target version information has the compatibility to run the lightweight program corresponding to the development environment version information.

[0007] Secondly, embodiments of this application also provide an electronic device, which includes: One or more processors; Storage device, configured to store one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the version matching method described in the embodiments of this application.

[0008] Thirdly, embodiments of this application also provide a non-volatile storage medium for storing computer-executable instructions, which, when executed by a computer processor, are configured to perform the version matching method described in embodiments of this application.

[0009] In this embodiment, development environment version information and reference environment version information are obtained; the development environment version information is matched with the reference environment version information, and target version information is determined from the reference environment version information. This ensures that the runtime environment configured with the target version information is compatible with running the lightweight program corresponding to the development environment version information. Based on the version of the development environment used by the developers, a runtime environment version compatible with the development environment version is determined through version matching. Local devices configured according to the runtime environment version can directly run the lightweight program. Developers do not need to consider compatibility issues that may exist during the operation of the lightweight program, and can flexibly choose the development environment according to their personal habits, reducing the adaptation cost to changes in the development environment. Attached Figure Description

[0010] Figure 1 A flowchart of the first version matching method provided in the embodiments of this application.

[0011] Figure 2 A flowchart of a second version matching method provided in an embodiment of this application.

[0012] Figure 3 A flowchart of the third version matching method provided in the embodiments of this application.

[0013] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the scope of the embodiments. Furthermore, it should be noted that, for ease of description, only the parts relevant to the embodiments of this application are shown in the accompanying drawings, not the entire structure.

[0015] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0016] After the lightweight application is developed by the R&D department based on the development environment, when users use the lightweight application on their local devices (such as mobile phones), the local devices also need to have an environment that supports the operation of the lightweight application. In other words, the operating environment of the local device needs to be compatible with the development environment of the lightweight application in order to ensure the normal operation of the lightweight application.

[0017] In related technologies, developers face high costs in adapting to changes in the development environment, and lightweight programs developed based on specific development environments have limited compatibility with the actual operating environment of local devices.

[0018] The applicant's in-depth analysis of the requirements of lightweight programs in the relevant technologies for both the development and operational environments revealed that the basic library in the development environment is the core support for lightweight program development. The basic library, through standardized interfaces, adaptability, and toolchain integration, lowers the development threshold for developers during the lightweight program development process and ensures the compatibility of lightweight programs during runtime. In the operational environment, the basic library supporting the operation of lightweight programs must at least cover all or core supporting capabilities of the basic library used as the core support during development to guarantee the implementation of all or core functions of the lightweight program in the actual operational environment.

[0019] In related technologies, a lightweight application platform provides a single base library version for developers to use as the foundation for lightweight application development. For developers, with only one base library that is continuously updated, they need to constantly adapt their development habits to these updates. For lightweight applications, those developed at different times, even if considered as different iterations of the same lightweight application, may not run correctly simultaneously under the same base library. This is because later-developed applications rely on new features added to the newer version of the base library, while earlier-developed applications, adapted to older versions, may fail or change in later versions, leading to functional abnormalities and crashes in a single base library environment. Ultimately, this results in high adaptation costs for developers to changes in the development environment, and limited compatibility of lightweight applications developed for specific development environments with the actual operating environment of local devices.

[0020] Based on the above analysis of the problem's symptoms and underlying causes, the applicant proposes a version matching method in this application. This method involves obtaining development environment version information and reference environment version information; matching the development environment version information with the reference environment version information; and determining the target version information from the reference environment version information. This ensures that the runtime environment configured with the target version information is compatible with running the lightweight program corresponding to the development environment version information. Based on the version of the development environment used by the developers, version matching determines the runtime environment version that is compatible with the development environment version. Local devices configured according to the runtime environment version can directly run the lightweight program. Developers do not need to consider potential compatibility issues during the lightweight program's operation and can flexibly choose the development environment according to their personal habits, reducing the adaptation cost to changes in the development environment.

[0021] The version matching method provided in this application embodiment can be applied to the process of determining whether the local device has compatibility with the lightweight program before the lightweight program runs on the local device. The execution subject of each step can be the local device, that is, the computer device. The computer device refers to any electronic device with data computing, processing and storage capabilities, such as PC (Personal Computer), tablet computer, mobile phone and other terminal devices. This application embodiment does not limit this.

[0022] Please refer to Figure 1 This is a flowchart of the first version matching method provided in the embodiments of this application, as follows: Figure 1 As shown, this version matching method includes, but is not limited to, steps S110-S120.

[0023] Step S110: Obtain development environment version information and reference environment version information.

[0024] In this embodiment, the development environment version information and the reference environment version information are used to describe the general information of the business-level software support, such as interfaces, components, and underlying algorithms, that support the operation of the lightweight program in its current state. For the lightweight program, the business-level software support, such as interfaces, components, and underlying algorithms, is defined as a basic library. The general information of the basic library corresponding to the development stage of the lightweight program is defined as the development environment version information, and the general information of the basic library used to determine whether to configure it on a local device as support for the operation of the lightweight program is defined as the reference environment version information. The processing goal of the version configuration method in this embodiment is to identify a target version information from the reference environment version information. After the basic library corresponding to the target version information is deployed on a local device, the lightweight program can run normally on that local device, that is, it has compatibility with the lightweight program.

[0025] The base library is made available to developers of lightweight applications by the lightweight application platform. It encapsulates the core capabilities required for lightweight applications, allowing developers to implement functionalities directly by calling APIs without needing to concern themselves with the underlying implementation. Core capabilities include the rendering layer (webview.js provides page and component rendering capabilities), the logic layer (service.js provides event handling and data binding capabilities), and the page framework (pageFrame.html provides page layout templates). Extended capabilities such as network requests (xx.request), local storage (xx.setStorage), and device interaction (scanning, location, etc.) are all uniformly encapsulated and exposed to developers by the base library. Standardized components serving as basic interactive elements, such as built-in buttons, forms, and navigation, allow developers to directly reuse these core capabilities without custom development.

[0026] In a lightweight application platform, the maintenance and updating of the base library, based on the upgrades or additions of single functions as described above, forms the basis for implementing the version matching method in this application's embodiments. During maintenance and updates, multiple versions of the base library can be comprehensively managed, with each version distinguished by a version number. This allows for refined management of multiple versions and version matching as described in this application's embodiments, all based on the version number.

[0027] Each time the base library needs maintenance, the version type is determined based on the specific business requirements of that maintenance (e.g., adding new features, fixing bugs, refactoring interfaces, etc.), and the version number is defined according to the major.minor.patch semantic format, where major, minor, and patch represent the major version number, minor version number, and revision number, respectively. The version type can include major version, minor version, and revision. The major version (e.g., v2.0.0) is used for refactoring incompatible interfaces. The maintenance of the major version is a major base library maintenance matter. A deprecation notice can be issued to developers some time in advance (e.g., 6 months or longer), clearly informing developers of the decommissioning time of the old version of the base library, and simultaneously planning the deprecation of the corresponding historical compatible version of the base library, so as to implement the version matching method in this application embodiment and continue to maintain the running support of lightweight programs developed based on the old version of the base library. For example, the v1.3.0 version of the base library can be retained as the running support for lightweight programs developed based on the v1.3.0 version and earlier versions of the base library. Sub-versions (e.g., v1.3.0) only add backward compatibility features (such as a new Bluetooth interface), without modifying old interface logic. After development, they are packaged into a complete base package containing webview.js, service.js, and pageFrame.html. When upgrading the base library's sub-versions or revision numbers, old interfaces are not deleted; only new features are added or bugs are fixed. Older projects can adapt to higher versions of the base library without code modification. Revisions (e.g., v1.2.1) only fix bugs (such as the QR code scanning interface crash), and are internally iterated based on the corresponding sub-version source code, maintaining a consistent base package structure. The lightweight application platform provides multiple base libraries, as well as interfaces for log output and error capture. Combined with development tools, it enables breakpoint debugging and performance analysis, helping developers locate problems.

[0028] Within the lightweight application platform, each version of the base library requires internal testing. This includes performing integrity verification on the new base package, such as verifying the existence of necessary files and MD5 checksums; compatibility testing to match different lightweight application versions; and performance testing on loading speed, resource consumption, etc. During the release process, a canary release can be conducted first, pushing the new version of the base library to a certain percentage (e.g., 10%) of users via a remote service interface. Then, the matching success rate and crash rate are monitored over a certain period (e.g., 72 hours). If the crash rate is ≤0.5%, a full release is performed. After the full release, the version information and corresponding compatibility scope are updated, and the version index information (e.g., release date, changelog, download address, etc.) is synchronized to the configuration server.

[0029] The configuration server establishes a repository with multiple versions of the base library, storing complete base packages categorized by version number. Each version can be configured with multiple download addresses, covering downloads from different carriers. A dedicated database on the configuration server records information such as the version status of each base library version (e.g., test version, stable version, historically compatible version, obsolete version, etc.), download volume, usage frequency, and compatibility range, supporting remote matching and querying.

[0030] After the configuration server remotely receives the base package, it uses a dynamic download and installation process to decompress the base package to a specified local directory (e.g., ${APP_SUPPORT_DIR} / MiniApp / BaseLibrary / [version number] / ), and automatically generates a JSON-formatted version index file (index.json). The configuration server can use the local index file to record the install_date (installation time), last_used (last use time), use_count (number of uses), and status (integrity status) of each version in real time for local matching and filtering. The local index file can be maintained according to preset conditions. For example, when the local storage usage rate is >80%, automatic cleanup is triggered. Whether to clean up is determined based on the version status and the corresponding usage frequency. For example, priority is given to cleaning up obsolete versions and historical compatible versions that have not been used for a long time (e.g., 3 months or more), while retaining stable versions and the two most recently used historical compatible versions.

[0031] The configuration server allows for more in-depth maintenance of the locally stored base packages, providing data support for the lightweight application platform to analyze the operation of the base library. For example, it can generate core metrics in real time, such as local matching success rate, remote query response time, download success rate, crash rate, and usage percentage for each version. Furthermore, it can provide operational feedback based on these metrics; for instance, it can trigger an operational alarm to the lightweight application platform when the stable version crash rate exceeds 1% or the historical compatible version matching failure rate exceeds 10%. When all versions of the base packages become associated during the implementation of the version matching method in this embodiment, corresponding logs can also be generated. These logs record the entire process of matching, downloading, installing, and running for each version of the base package. The log information includes the version number, device information, and error codes. Each log entry can be set to be retained for a preset duration (e.g., 30 days).

[0032] Regarding the version status described above, version status can also be transitioned based on update behavior and log information. For example, after a stable version iteration, the old stable version becomes a historical compatibility version. If the historical compatibility version has a low usage rate for a relatively long period, such as a usage rate of <0.1% (or other percentage) for 3 consecutive months (or other durations), it becomes a deprecated version. Once the base library of a certain version is marked as deprecated, developers can be notified through developer documentation, management backend pop-ups, etc., and remote query support will be discontinued after a certain period of time, retaining only the usage rights of the locally installed version.

[0033] Through the above processing, all maintenance operations on the configuration server do not disrupt the compatibility between existing lightweight programs and their corresponding base libraries, avoiding functional abnormalities caused by maintenance; nor do they add an unlimited number of versions, controlling the number of active base library versions through a rotation and eviction mechanism to balance compatibility and storage maintenance costs. Moreover, when necessary, since operation logs are recorded for the creation, update, and decommissioning of each version, problem backtracking and version rollback can be supported based on the operation logs.

[0034] Based on the maintenance of multiple versions of the base library described above, the lightweight program development tool has built-in versions of the base library. Developers can select a target version for debugging and verify compatibility in advance. During the specific development process, developers can choose a version of the base library as the development foundation for the lightweight program according to their own development habits and the development needs of the lightweight program. The lightweight program file has a version declaration mechanism, and developers can declare the minimum version of the required base library through the declaration file (e.g., libVersion: "1.2.0"). The base library ensures that the interfaces called during development exist in the target version through a semantic version management module. For developers, the design based on the base library shields the differences between different devices and systems (e.g., rendering adaptation between iOS and Android), allowing developers to focus on business logic development. After development is completed, the version interface is declared according to the version number of the base library used. That is, the process of generating development environment version information in this embodiment includes: obtaining the development version information corresponding to the runtime environment that serves as the development foundation of the lightweight program; adding the development version information, or the version range determined based on the development version information, to the configuration file of the lightweight program as development environment version information. Based on the version numbers of the base libraries used by developers during the development of the lightweight application, the development environment version information is automatically generated and added to the declaration file. The lightweight application can automatically match this information at runtime, achieving compatibility between the user's local device and the lightweight application in a way that is imperceptible to the user, thus ensuring the normal operation of the lightweight application.

[0035] In another alternative implementation, developers can test the compatibility of the planned lightweight program on mainstream computer devices before development. This involves collecting multiple computer devices, and on each device, inputting the version number of the planned base library through a pre-defined interface. This version number serves as the development environment version information for this embodiment. The processing results of each step in the version matching process described in this embodiment are monitored to confirm compatibility. If compatible, the compatibility method needs to be determined, thus deciding whether to develop the lightweight program or adjust the base library used, ensuring that the final lightweight program can run on as many computer devices as possible.

[0036] Step S120: Match the development environment version information with the reference environment version information, and determine the target version information from the reference environment version information so that the runtime environment configured with the target version information has the compatibility to run the lightweight program corresponding to the development environment version information.

[0037] In this embodiment, both the development environment version information and the reference environment version information (i.e., version number) are strings generated according to predetermined rules. During the matching process, the string corresponding to the version number is first parsed into a structured object, and then compatibility verification and matching are performed based on semantic rules. Accurate matching is achieved through standardized data structures and fixed algorithms, avoiding ambiguity in string comparison. That is, based on obtaining two relative matching objects, during the matching process, the development environment version information and the reference environment version information are first structurally converted to obtain a development structured object and a reference structured object; then, the development structured object and the reference structured object are matched according to their corresponding fields. If all target fields satisfy the preset compatibility rules, the matching result is determined to be compatible, where the target fields are the fields associated with the compatibility rules.

[0038] For the development environment version information declared in the lightweight application (e.g., version number "1.2.0" in string form) and the reference environment version information obtained (e.g., version numbers "1.2.1" and "1.3.0" in string form), ensure that both are in the major.minor.patch format.

[0039] If the version number has an abbreviation, such as "1.2", it will be automatically completed to the full format "1.2.0". If it contains a non-numeric suffix, such as "1.2.0-beta", the suffix will be removed and only the core version number will be kept, that is, only "1.2.0" will be kept for matching.

[0040] For version numbers that exist as strings and have a complete defined structure, a version parsing algorithm converts the version numbers corresponding to the development environment version information and the version numbers corresponding to the reference environment version information into structured objects, thereby extracting three core fields: major, minor, and patch. During parsing, the string can be split according to specific symbols, such as using "." to split the version string, and values ​​are assigned to the corresponding fields sequentially. Missing fields are filled with 0 by default, and missing fields are filled starting from the last field. For example, "1.2" is parsed as major:1, minor:2, patch:0, not major:1, minor:0, patch:2).

[0041] Given a complete structure and corresponding field numbers, compatibility is assessed field by field according to the corresponding compatibility rules. First, the major version numbers must be identical (except where preset compatibility rules allow for different major version numbers). Consistent major version numbers guarantee core compatibility; different major version numbers usually indicate interface incompatibility. Second, the minor version number of the base library must be greater than or equal to the minor version number of the required version (a higher minor version number indicates functional compatibility or bug fixes). Finally, the revision number of the base library must be greater than or equal to the revision number of the required version (a higher revision number indicates functional compatibility or bug fixes). Only when all three conditions are met simultaneously is the reference environment version information deemed compatible with the development environment version information representing the lightweight program requirements considered compatible. In other words, the matching in this embodiment does not necessarily require all field numbers to be identical. When the base library version number is updated incrementally in the corresponding field according to version type, and the major version number is the same, a larger minor version number and a later update time result in a wider range of compatibility. Meeting these conditions ensures compatibility with the development environment version information. It should be understood that in some scenarios, a new version of the base library may still be compatible with an older version, but the major version number may be redefined when defining a new version number. In such cases, the compatibility of these major version numbers can be judged separately to complete version matching. That is, version numbers with different major version numbers but compatible relationships are recorded separately. When the obtained development environment version information belongs to a separately recorded version number, the compatibility relationship of the separately recorded version number is used as a preset compatibility rule to determine the compatibility between the obtained development environment version information and the reference environment version information. For example, if the major version number of the base library C is different from that of the base library B, but the base library C is compatible with the base library B, and the obtained development environment version information is the version information corresponding to the base library B, if the local version information is the version information of the base library C, then the compatibility relationship of the separately recorded version can be used to determine that the reference environment version information is compatible with the development environment version information.

[0042] In the actual matching process, multiple reference environment version information may be compatible with the development environment version information. In this case, the multiple compatible reference environment version information can be arranged in descending order of minor version number → descending order of revision number. Then, the latest compatible version number is selected as the target version information. Then, the corresponding runtime environment is built according to the source of the target version information. If the target version information is directly the version number of the base library in the current runtime environment of the computer device, it can be kept as is. If the target version information is a version number obtained remotely, the corresponding base library is downloaded and built on the computer device. In the specific implementation, any reference environment version information that is compatible with the development environment version information can be used as the target version information.

[0043] The following is a description of the matching process based on the specific development environment version information and the reference environment version information.

[0044] In the first scenario, based on step S110, the development environment version information (version number "1.2.0") and a reference environment version information (version number "1.2.1") are obtained. For version number "1.2.0", the structured object parsed from "." is {major:1, minor:2, patch:0}. For version number "1.2.1", the structured object parsed from "." is {major:1, minor:2, patch:1}. The fields in the structured objects are then evaluated for compatibility according to the compatibility rules described earlier. Major version number: 1=1 (satisfies the compatibility rules); Minor version number: 2≥2 (satisfies the compatibility rules); Revision number: 1≥0 (satisfies the compatibility rules). Therefore, the matching result is confirmed to be compatible, and the reference environment version information can be used as the target version information. If the reference environment version information is the version number of the computer device's current operating environment, then the computer device's current operating environment can be maintained; if the reference environment version information is obtained from the configuration server, then the computer device needs to obtain the corresponding basic library from the configuration server to rebuild the operating environment in order to achieve compatibility with lightweight programs on the computer device.

[0045] In the second scenario, based on step S110, the development environment version information (version number "1.2.0") and multiple reference environment version information (version numbers "1.0.5", "1.1.2", "1.2.0", "2.0.0", and "1.1.0") are obtained. For version number "1.2.0", the structured object parsed based on "." is {major:1, minor:1, patch:0}. For version numbers "1.0.5", "1.1.2", "1.2.0", "2.0.0", and "1.1.0", based on the structured object parsed from ".", the simplified representations before and after conversion are: "1.0.5" → {1,0,5}, "1.1.2" → {1,1,2}, "1.2.0" → {1,2,0}, "2.0.0" → {2,0,0}, and "1.1.0" → {1,1,0}.

[0046] The matching process and results between the development environment version information and each reference environment version information are simply represented as follows: Version number "1.0.5": Minor version number 0 < 1 (incompatible, discarded); Version number "1.1.2": Major version number 1=1, minor version number 1≥1, revision number 2≥0 (compatible); Version number "1.2.0": Major version number 1=1, minor version number 2≥1, revision number 0≥0 (compatible); Version number "2.0.0": Major version number 2 ≠ 1 (incompatible, removed); Version number "1.1.0": Major version number 1=1, minor version number 1≥1, revision number 0≥0 (compatible); Based on the above matching results, it can be determined that version numbers "1.1.2", "1.2.0" and "1.1.0" are compatible with version number "1.2.0". These compatible version numbers are then sorted according to the order of their minor version number and revision number, following the sorting logic described earlier. The sorting result is: "1.2.0" (minor version number 2) > "1.1.2" (minor version number 1, revision number 2) > "1.1.0" (minor version number 1, revision number 0). Finally, "1.2.0", which ranks first in the sorting, is taken as the final target version information.

[0047] In the third scenario, based on step S110, the development environment version information (version number "2.0.0") and a reference environment version information (version number "1.3.5") are obtained. For version number "1.2.0", the structured object parsed based on "." is {major:2, minor:0, patch:0}. For version number "1.3.5", the structured object parsed based on "." is {major:1, minor:3, patch:5}. The matching process between the development environment version information and the reference environment version information is as follows: Major version: 1 ≠ 2 (core condition not met); the reference environment version information is incompatible with the development environment version information, and the base library corresponding to this version number is excluded.

[0048] In both the first and second scenarios, a specific processing strategy for the current environment is determined based on the target version information: either maintain the current runtime environment or download the base library from the configuration server and rebuild the runtime environment. If no target version information is found, a version rollback is performed on the current runtime environment to ensure compatibility with the lightweight program. In this approach, the current runtime environment may only support the core processing of the lightweight program, and the lightweight program may only implement some of its intended functions during operation, providing the user with a notification of incomplete functionality.

[0049] Additionally, it should be noted that, from an overall implementation logic perspective, obtaining development environment version information and reference environment version information can be achieved by first obtaining reference environment version information from multiple sources, then matching them sequentially according to the source. Once the target version information is determined, the matching process can be terminated, and a runtime environment compatible with the lightweight program can be configured based on the target version information. Alternatively, obtaining development environment version information and reference environment version information can be achieved by first obtaining reference environment version information from one source, then matching the reference environment version information from that source. Once the target version information is determined, the matching process can be terminated, and no further acquisition of reference environment version information is required. A runtime environment compatible with the lightweight program can then be configured based on the target version information. In other words, steps S110 and S120 in this embodiment are only used to describe the overall implementation idea and do not represent an absolute limitation on the specific execution order of the steps. For example, to obtain development environment version information and reference environment version information, all reference environment version information can be obtained at the beginning and then matched sequentially; or a match can be performed once a reference environment version information is obtained. The specific process of obtaining reference environment version information and performing matching is carried out in an overlapping manner, but it does not deviate from the overall design concept of the embodiments of this application.

[0050] In summary, by acquiring development environment version information and reference environment version information, matching the development environment version information with the reference environment version information, and determining the target version information from the reference environment version information, the runtime environment configured with the target version information is compatible with running the lightweight program corresponding to the development environment version information. Based on the version of the development environment used by the developers, the runtime environment version that is compatible with the development environment version is determined through version matching. Local devices configured according to the runtime environment version can directly run the lightweight program. Developers do not need to consider potential compatibility issues during the operation of the lightweight program, and can flexibly choose the development environment according to their personal habits, reducing the adaptation cost to changes in the development environment.

[0051] Please refer to Figure 2 This is a flowchart of the second version matching method provided in the embodiments of this application, as follows: Figure 2 As shown, this version matching method includes, but is not limited to, steps S210-S240.

[0052] Step S210: Obtain development environment version information and reference environment version information.

[0053] In this embodiment, local version information and candidate version information are used. The local version information is the environment version information of the current running environment, and the candidate version information is pre-stored environment version information that can be configured as the current running environment. Both local and candidate version information are obtained centrally, and subsequent matching is based solely on their order. The order of the local version information precedes the order of the candidate version information. If there are multiple candidate version information entries, they can be matched in any order. That is, in the process of obtaining development environment version information and reference environment version information, in addition to obtaining development environment version information from the lightweight program's declaration file or from user input data, reference environment version information is also obtained from preset sources using corresponding acquisition methods. Furthermore, the local version information is ranked before candidate version information obtained from other sources in the matching order.

[0054] In the process of obtaining reference environment version information from computer devices, you can first scan the computer device's base library storage directory, for example, access the path ${APP_SUPPORT_DIR} / MiniApp / BaseLibrary / , traverse all subdirectories named with semantic version numbers (such as "1.2.0 / " "1.3.0 / "), and extract the directory names as a list of installed versions.

[0055] An example of the structure of the basic library storage directory in a computer device is shown below: ${APP_SUPPORT_DIR} / MiniApp / BaseLibrary / ├── index.json / / Version index file ├── 1.2.0 / / / Version Directory │├── webview.js / / Rendering layer base library │├── service.js / / Basic library for the logic layer │└── pageFrame.html / / Page Frame ├── 1.2.1 / │├── webview.js │├── service.js │└── pageFrame.html └── 1.3.0 / ├── webview.js ├── service.js └── pageFrame.html Read the index.json file, also known as the version index file, from each subdirectory named with a semantic version number. An example version index file is shown below: { "last_update": "2024-01-15T10:30:00Z", "versions": { "1.2.0": { "install_date": "2024-01-10T08:20:00Z", "last_used": "2024-01-14T16:45:00Z", "use_count": 15, "size": 1536000, "status": "complete" }, "1.2.1": { "install_date": "2024-01-12T14:15:00Z", "last_used": "2024-01-15T09:30:00Z", "use_count": 8, "size": 1548000, "status": "complete" } } } Extract metadata such as "install_date", "last_used", and "status" for each version number, and filter out the initial versions with a status of "complete". For each initial version, check the existence and readability of the three required files: webview.js, service.js, and pageFrame.html, and discard invalid versions with missing or corrupted files to obtain valid versions. The version number corresponding to the valid version is the development environment version information.

[0056] By using the above method to obtain development environment version information from the local device, real-time collection can be performed at the start of version matching. The version number of the base library remains up-to-date with the synchronized index file, ensuring data accuracy and guaranteeing the acquisition of the latest development environment version information. In the specific implementation, if directory scanning fails or the index file is corrupted, the base library directory can be automatically rebuilt, loading the default base library version built into the container to ensure uninterrupted matching. Only the core fields necessary for matching are collected, avoiding performance degradation due to redundant data collection. Based on this, matching time can be less than 100ms.

[0057] For the reference environment version information recorded on the configuration server, the configuration server provides a dedicated interface for querying the reference environment version information. During the process of requesting the reference environment version information, the necessary query information in the corresponding format is provided according to the definition of the interface. The necessary query information includes, for example, the version number of the base library declared by the lightweight application (e.g., "1.2.0") and the client version of the lightweight application container (e.g., "3.5.0"). In addition, optional auxiliary query information may also be included, such as device model, system version, etc., so that the configuration server can return a more accurate adaptation version.

[0058] If only the necessary query information is provided, the reference environment version information and download information can be quickly obtained. If auxiliary query information is also provided, detailed information about the reference environment version information (such as release date and changelog) can be obtained.

[0059] Step S220: Determine the matching order of the reference environment version information based on the source of the reference environment version information.

[0060] In the specific implementation, when multiple reference environment version information is obtained, the priority relationship defined by source is used, meaning the local version information precedes the candidate version information. If there are multiple local version information, the overall matching order is randomly determined before the candidate version information; conversely, if there are multiple reference environment version information, the overall matching order is randomly determined after the local version information.

[0061] Step S230: Match the development environment version information with the reference environment version information one by one according to the matching order, and determine the matching result of the reference environment version information with the development environment version information regarding compatibility each time.

[0062] Step S240: Determine the target version information based on the matching result.

[0063] In this embodiment, the development environment version information is matched one by one with the reference environment version information. Therefore, when a matching result is found to be compatible, the reference environment version information associated with that matching result can be directly used as the target version information, and the matching process can be terminated. Alternatively, if the matching result of the local version information is incompatible, all candidate version information can be matched, and one of the candidate version information with compatible matching results can be selected for use.

[0064] When a matching result is found to be compatible, the reference environment version information associated with the matching result is directly used as the target version information, and the matching is terminated. This is equivalent to the process of determining the target version information based on the matching result in step S240, including steps S241 and S242.

[0065] Step S241: If the matching result is compatible, the reference environment version information corresponding to the current position is used as the target version information.

[0066] The specific matching process has been described in the previous embodiment. For multiple candidate version information obtained from the configuration server, if the matching result is compatible, any matching candidate version information can be used as the target version information. Of course, it can also be sorted according to the sorting logic described above, and the candidate version information with the highest sorting result can be used as the target version information.

[0067] The implementation process of steps S210-S240 will be described in detail below with reference to a specific implementation process.

[0068] The libVersion field read from the lightweight program configuration file yields the version number declared by the lightweight program: v1.2.0. This version number is the development environment version information.

[0069] During the centralized acquisition of reference environment version information, a valid version number, v1.2.0, was obtained from the computer device. This version number represents the local version information. It was scanned and extracted from the local storage directory ${APP_SUPPORT_DIR} / MiniApp / BaseLibrary / , with the version index file index.json marked with status: "complete," and its integrity was verified through necessary files such as webview.js. The interface / interface / miniapp / base-library / compatible was called to retrieve three candidate version information and download information from the configuration server, as shown in the table below:

[0070] In the specific matching process, the development environment version information is first matched with the local version information. The corresponding strings are then parsed to obtain structured objects. Specifically, the structured object obtained from parsing the development environment version information v1.2.0 is (major:1, minor:2, patch:0), and the structured object obtained from parsing the local version information v1.2.0 is (major:1, minor:2, patch:0).

[0071] Structured objects are used as direct matching objects. According to the preset compatibility rules, major version number: 1=1 (satisfied); minor version number: 2≥2 (satisfied); revision number: 0≥0 (satisfied). Therefore, it can be determined that the local version information is directly compatible with the development environment version information. v1.2.0 is directly used as the target version, which means that the lightweight program can be directly loaded and run on the computer device, and the matching process terminates.

[0072] If the local version information obtained centrally is v1.1.0 (the development environment version information is still v1.2.0), the first match will fail, and the process of matching the development environment version information with the candidate version information will begin.

[0073] The three candidate version information described above is structured and parsed. The data before and after parsing are as follows: v1.2.1 → (1,2,1); v1.3.0 → (1,3,0); v1.2.0 → (1,2,0).

[0074] Based on the compatibility rules, it can be found that all three candidate version information are compatible with the development environment version information.

[0075] The three candidate version information were sorted according to the principle of "minor version in descending order → revision number in descending order", and the result was: v1.3.0 > v1.2.1 > v1.2.0. The first-ranked v1.3.0 was selected as the target version.

[0076] Another example is a development environment version information of v1.3.0, which parses to (1,3,0). The candidate version information obtained from the configuration server is: v1.2.1, v1.3.0, and v2.0.0. The corresponding matching results are: the local version information is v1.2.0, which parses to (1,2,0), the minor version number 2 < 3, and the matching result is incompatible. For the candidate version information, v1.2.1 (1,2,1): minor version 2 < 3 (incompatible); v1.3.0 (1,3,0): fully compatible (reserved); v2.0.0 (2,0,0): major version 2 ≠ 1 (incompatible). Only v1.3.0 is compatible and is therefore used as the target version information.

[0077] After determining the target version information from the candidate version information, configuration data is requested from the configuration server based on the target version information to configure the current operating environment.

[0078] In the download and installation environment configuration phase, a download task is created using the main download address returned by the server: https: / / cdn.example.com / base-lib / 1.3.0.zip. Resume download and concurrency control are enabled. After downloading, the MD5 hash of the file is verified to match the def456... returned by the server, and webview.js, service.js, and pageFrame.html are all present and readable. The base library files are extracted to the local storage directory 1.3.0 / , and index.json is updated, adding metadata for v1.3.0 (install_date: "2024-05-20T14:30:00Z", status: "complete"). After successful installation, v1.3.0 is loaded and the lightweight program is run, completing the matching process.

[0079] During the download of the base library and the completion of the installation, a download task is created through the KIMPackageRequest module. In this embodiment, an HTTP download task is created based on the main download address, and the local storage directory ${APP_SUPPORT_DIR} / MiniApp / BaseLibrary / temp / 1.2.3.zip is specified. This directory is a temporary directory to avoid polluting the official directory when the installation is interrupted. The download task is also configured to resume interrupted downloads, record the number of bytes downloaded (initially 0), and add Range: bytes=0- to the request header to support resuming the download after network interruption.

[0080] During the download process based on download tasks, the download progress (number of bytes downloaded / total number of bytes) is calculated in real time. In interactive mode, the download progress is displayed to the user, such as a text display of "Downloading -30%" or an image-based display. In silent mode, only logs are recorded. If the download speed from the main address is <100KB / s or the download fails, it automatically switches to the backup mirror address (in the order of the mirrors array). During the download process, the task queue of the download management module also limits the number of simultaneous download tasks to ≤3 to avoid excessive consumption of CPU and network resources. When the number of downloaded bytes equals the file size, the download is considered complete, and the temporary file 1.2.3.zip is moved to the ${APP_SUPPORT_DIR} / MiniApp / BaseLibrary / directory. If the download is interrupted (e.g., the user switches networks, or the process is killed in the background), the number of downloaded bytes in the temporary file is automatically read upon the next startup, and the download continues.

[0081] For the downloaded file, the MD5 checksum has already been obtained from the configuration server response; the text itself can be verified by the local verification module to perform MD5 hash calculation on the downloaded file and obtain the local MD5 value.

[0082] During the verification process, MD5 checksum and required file existence check are performed. Regarding MD5 checksum, if the local MD5 value matches the MD5 checksum returned by the configuration server, proceed to the next step; if they do not match, mark it as "verification failed," delete the current file, and re-download it, with a maximum of two retries. If the MD5 checksum passes, the required file existence check is performed. During this check, 1.2.3.zip is unzipped to the version directory ${APP_SUPPORT_DIR} / MiniApp / BaseLibrary / 1.2.3 / , and then the presence of three required files is checked in the unzipped directory: webview.js (rendering layer base library, approximately 800KB), service.js (logic layer base library, approximately 600KB), and pageFrame.html (page frame file, approximately 50KB). These three files must exist and be readable (no permission restrictions, no file corruption). If any file is missing, the verification fails, triggering a re-download, with a maximum of two retries.

[0083] If both verifications pass, the version directory status is marked as pending installation, and the index update process begins. If the cumulative number of failures is ≥2, the system switches to the last backup mirror address to re-download; if this also fails, the default base library is used.

[0084] During the deployment of the base library, first update the local version index file index.json, adding the metadata for v1.2.3. The specific update method is as follows: json { "last_update": "2024-05-20T16:30:00Z", "versions": { "1.2.3": { "install_date": "2024-05-20T16:30:00Z", "last_used": "", "use_count": 0, "size": 2097152, "status": "complete" }, / / Other version metadata... } } The status: "complete" indicates that the version is available, and install_date records the installation time.

[0085] After the index file is successfully updated, v1.2.3 becomes the local valid base library version, which can be called when the lightweight program starts. After the configuration is completed, the download result log can be further reported to the configuration server: {"app_id":"xxx","required_version":"1.2.0","download_version":"1.2.3","status":"success","device_info":"iPhone 15"}, for the platform to collect statistics on the adaptation status.

[0086] During the download and configuration process, breakpoint resumption based on multiple mirror addresses ensures a download success rate of >95%. MD5 checksums and required file verification are used comprehensively for the downloaded basic libraries to prevent invalid package installations, effectively reducing compatibility issues by 90%. After downloading, the version matching engine directly loads v1.2.3 to run the lightweight program, eliminating the need for secondary matching. After local index updates, this version will serve as a local candidate version for subsequent lightweight program matching, improving matching efficiency.

[0087] Step S242: If the matching result is incompatible, match the development environment version information with the reference environment version information of the next sequence, or terminate the matching.

[0088] If the matching result is incompatible, the development environment version information is matched with the reference environment version information of the next sequence, or the matching is terminated. This means that if the matching result based on the local version information is incompatible, the development environment version information is matched with the reference environment version information of the next sequence. Before all candidate version information matching is completed, if the matching result of any candidate version information is incompatible, the development environment version information is also matched with the reference environment version information of the next sequence. If the matching result of the last candidate version information is incompatible, it indicates that there is no reference environment version information that is compatible with the development environment version information, and the matching is terminated.

[0089] In this embodiment, version rollback processing of the current runtime environment can be performed under at least two conditions. The first condition is that if the matching results for all reference environment version information are incompatible, the matching is terminated, and version rollback processing is performed on the current runtime environment to ensure compatibility with the lightweight program. The second condition is that version rollback processing is performed on the current runtime environment if the configuration data request fails, ensuring compatibility with the lightweight program. Failure to request configuration data can be a failure at any stage before successful configuration, such as download failure or verification failure.

[0090] Version rollback refers to configuring a runtime environment based on the default base library on a computer device. The default base library originates from the lightweight application container. Developed and released by the lightweight application platform, the lightweight application container pre-packages and integrates the default base library. This means the default base library is packaged together with the lightweight application container's installation package. When a user installs the lightweight application container, the default base library is automatically written to the computer device's local built-in version directory. The default base library has a dedicated, non-deletable storage path. In other words, after the lightweight application container is installed, the default base library is stored in the container's system-level built-in directory, such as ${APP_BUNDLE_DIR} / BuiltInBaseLibrary / . This directory is read-only and cannot be deleted by the cache cleanup mechanism, ensuring its permanent availability.

[0091] The default base library is usually an early stable version of the base library (e.g., v1.0.0). Its feature set only includes the interfaces necessary for the core operation of a lightweight application, such as page rendering, basic data binding, and simple network requests. The version number is fixed for a long time and will not change unless there is a major iteration of the container (such as a refactoring of the underlying architecture).

[0092] The default base library requires no network download and does not rely on a locally cached version index file (index.json). Even if the device is offline, the local cache directory is corrupted, or there are no cached versions, it can be loaded directly, achieving dependency-free usability. The default base library only retains the core basic capabilities for running lightweight applications, excluding extended features added in higher versions (such as Bluetooth, QR code scanning, and advanced rendering components), but it ensures that lightweight application pages display correctly and core logic executes, preventing the lightweight application from crashing. Aiming for compatibility with all historical lightweight applications: the default base library's interface fully complies with the earliest base library specifications. All lightweight applications developed according to earlier specifications (regardless of the declared version) can run in the default base library. It should be understood that features in lightweight applications that only depend on higher version base libraries will receive a downgrade warning indicating that they are not currently supported.

[0093] In an exemplary application scenario, suppose the matching process of the lightweight program C (development environment version information v2.0.0) includes local matching failure (due to the lack of a local v2.0.0 compatible version) and remote matching failure (due to network disconnection, even after 3 retries, the server interface still cannot be accessed). At this time, a fallback mechanism based on the default base library can be triggered, that is, the default base library v1.0.0 in the built-in version directory is directly called to load its webview.js (the core file in the built-in directory), service.js, and pageFrame.html. The core page of the lightweight program is rendered normally. Only the Bluetooth function, which relies on the new interface added in v2.0.0, prompts that the current version does not support the function, but the overall operation is not interrupted.

[0094] After matching all candidate version information, the specific matching process of using any compatible candidate version information as the target version information, and the process of configuring the current running environment based on the target version information, can be referred to the specific implementation method in any embodiment, and will not be elaborated here. It should be understood that the matching of candidate version information described in the embodiments of this application refers to matching the development environment version information with the candidate version information.

[0095] In summary, by centrally acquiring development environment version information and reference environment version information, and then matching the development environment version information with the centrally acquired reference environment version information one by one, the target version information is determined from the reference environment version information. This ensures that the runtime environment configured with the target version information is compatible with running the lightweight program corresponding to the development environment version information. Based on the version of the development environment used by the developers, the runtime environment version that is compatible with the development environment version is determined through version matching. Local devices configured according to the runtime environment version can directly run the lightweight program. Developers do not need to consider potential compatibility issues during the operation of the lightweight program, and can flexibly choose the development environment according to their personal habits, reducing the adaptation cost to changes in the development environment.

[0096] Please refer to Figure 3 This is a flowchart of the third version matching method provided in the embodiments of this application, as follows: Figure 3 As shown, this version matching method includes, but is not limited to, steps S310-S340.

[0097] Step S310: Obtain the development environment version information and obtain the local version information of the current running environment as the reference environment version information.

[0098] In this embodiment, a matching process is performed for each reference environment version information obtained. The first reference environment version information obtained is the local version information of the current operating environment of the computer device. The process of obtaining the local version information from the computer device can be referred to the description in the previous embodiment, and will not be repeated here.

[0099] Step S320: Match the development environment version information with the local version information.

[0100] Step S330: If the local version information is determined to be compatible with the development environment version information based on the matching result, the local version information is used as the target version information.

[0101] For a single match, the specific matching process and the determination of the target version information based on the matching result can be referred to the description in the previous embodiment, and will not be elaborated here.

[0102] Step S340: If it is determined that the local version information is incompatible with the development environment version information, obtain candidate version information as reference environment version information. The candidate version information is pre-stored environment version information that can be configured as the current running environment.

[0103] After determining the compatibility between the local version information and the development environment version information, and confirming that the local version information is incompatible with the development environment version information, candidate version information is obtained from other sources, such as a configuration server, as reference environment version information. The candidate version information in the configuration server can correspond to one or more base libraries. This candidate version information can be obtained all at once and matched one by one, or it can be obtained and matched sequentially before obtaining other candidate version information, until all candidate version information has been obtained and matched. The process of obtaining candidate version information from the configuration server can be referred to the description in the previous embodiment, and will not be repeated here.

[0104] Step S350: Match the development environment version information with the candidate version information. If the candidate version information is found to be compatible with the development environment version information based on the matching result, take any matching candidate version information as the target version information.

[0105] The specific matching process between development environment version information and candidate version information is described above. After determining the target version information from the candidate version information, configuration data is requested from the configuration server based on the target version information to configure the current runtime environment. When obtaining the candidate version information, the corresponding download address is also obtained. Accordingly, configuration data is requested based on the download address corresponding to the target version information, that is, the corresponding version of the basic library is downloaded and configured on the computer device, thus achieving compatibility of the computer device with the lightweight program.

[0106] In the specific implementation process, if the candidate version information is determined to be incompatible with the development environment version information based on the matching results, a version rollback is performed on the current runtime environment to ensure compatibility with the lightweight program. Similarly, if the configuration data request fails, a version rollback can also be performed on the current runtime environment to ensure compatibility with the lightweight program. Specific rollback procedures can be found in the description of the previous embodiment.

[0107] In summary, this method involves acquiring development environment version information and sequentially acquiring reference environment version information. After each acquisition of reference environment version information, the development environment version information is matched with the reference environment version information. If it can be directly identified as the target version information, the matching process ends. If it cannot be identified as the target version information, the next reference environment version information is acquired. This ensures that the runtime environment configured with the target version information is compatible with running the lightweight program corresponding to the development environment version information. Based on the version of the development environment used by the developers, the runtime environment version that is compatible with the development environment version is determined through version matching. Local devices configured according to the runtime environment version can directly run the lightweight program. Developers do not need to consider potential compatibility issues during the operation of the lightweight program and can flexibly choose the development environment according to their personal habits, reducing the adaptation cost to changes in the development environment.

[0108] It should be further explained that the processes of obtaining reference environment version information and matching to determine target version information in the embodiments of this application can be flexibly executed as long as they do not conflict with each other. For example, after centrally obtaining the reference environment version information, matching can begin one by one from the local version information. As long as the matching result is compatible, the target version information is determined and the matching is terminated. Alternatively, local version information can be obtained first and then matched. If the matching result is compatible, the local version information can be directly determined as the target version information and the matching is terminated. If the matching result is incompatible, candidate version information can be obtained one by one and matched, or candidate version information can be centrally obtained and matched one by one. After each matching, it can be determined whether the currently matched candidate version information is the target version information and whether to terminate the matching. Alternatively, candidate version information can be centrally obtained and matched. If multiple candidate version information with compatible matching results exist, one can be selected as the target version information. All of the above do not deviate from the design concept of this application.

[0109] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device includes a processor 410 and a memory 420. In one possible product form of the electronic device, it may also include an input device 430, an output device 440, and a communication device 450. The number of processors 410 in the electronic device can be one or more. Figure 4 Taking a processor 410 as an example; the processor 410, memory 420, input device 430, output device 440, and communication device 450 in the electronic device can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0110] The memory 420, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the version matching method in the embodiments of this application. The processor 410 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 420, thereby implementing the aforementioned version matching method.

[0111] The memory 420 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 420 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 420 may further include memory remotely located relative to the processor 410, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0112] Input device 430 can be used to receive network configuration information. Output device 440 may include electronic devices such as a display screen.

[0113] The aforementioned electronic device can be used to execute any version of the matching method, possessing the corresponding functions and beneficial effects.

[0114] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and equipment can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0115] Furthermore, embodiments of this application also provide a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform relevant operations in the version matching method provided in any embodiment of this application, and have corresponding functions and beneficial effects.

[0116] Those skilled in the art will understand that embodiments of this application may be provided as methods, systems, or computer program products.

[0117] Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce implementations of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0118] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0119] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0120] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0121] The above specific embodiments have further detailed the purpose, technical solution, and beneficial effects of this application. It should be understood that the above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application for those skilled in the art.

Claims

1. A version matching method, characterized in that, include: Obtain development environment version information and reference environment version information; The development environment version information is matched with the reference environment version information, and the target version information is determined from the reference environment version information so that the runtime environment configured with the target version information has the compatibility to run the lightweight program corresponding to the development environment version information.

2. The version matching method according to claim 1, characterized in that, The step of matching the development environment version information with the reference environment version information and determining the target version information from the reference environment version information includes: The matching order of the reference environment version information is determined based on its source. According to the matching order, the development environment version information is matched with the reference environment version information one by one, and the matching result of the reference environment version information with the development environment version information regarding compatibility is determined each time. The target version information is determined based on the matching results.

3. The version matching method according to claim 2, characterized in that, The reference environment version information includes local version information and candidate version information. The local version information is the environment version information of the current running environment, and the candidate version information is the pre-stored environment version information that can be configured as the current running environment. The local version information is ordered before the candidate version information in the matching order.

4. The version matching method according to claim 2 or 3, characterized in that, Determining the target version information based on the matching result includes: If the matching result is compatible, the reference environment version information associated with the matching result will be used as the target version information. If the matching result is incompatible, the development environment version information will be matched with the next reference environment version information, or the matching will be terminated.

5. The version matching method according to claim 3, characterized in that, After matching the development environment version information with the reference environment version information one by one according to the matching order, and determining the matching result of the reference environment version information with the development environment version information regarding compatibility at each time, the method further includes: If the matching result is compatible and the reference environment version information associated with the matching result is candidate version information, then any candidate version information that is compatible with the matching result shall be used as the target version information.

6. The version matching method according to claim 4, characterized in that, If the matching result is incompatible, the process of matching the development environment version information with the reference environment version information of the next sequence, or terminating the matching, includes: If the matching results for all reference environment version information are incompatible, the matching is terminated, and the current running environment is rolled back to ensure that the current running environment is compatible with the lightweight program.

7. The version matching method according to claim 1, characterized in that, The acquisition of development environment version information and reference environment version information includes: Obtain the development environment version information and use the local version information of the current running environment as the reference environment version information.

8. The version matching method according to claim 7, characterized in that, The step of matching the development environment version information with the reference environment version information and determining the target version information from the reference environment version information includes: Match the development environment version information with the local version information; If the local version information is determined to be compatible with the development environment version information based on the matching results, the local version information shall be used as the target version information.

9. The version matching method according to claim 7, characterized in that, The acquisition of development environment version information and reference environment version information includes: If it is determined that the local version information is incompatible with the development environment version information, candidate version information is obtained as reference environment version information. The candidate version information is pre-stored environment version information that can be configured as the current running environment.

10. The version matching method according to claim 9, characterized in that, The step of matching the development environment version information with the reference environment version information and determining the target version information from the reference environment version information includes: Match the development environment version information with the candidate version information; If the candidate version information is determined to be compatible with the development environment version information based on the matching results, any matching candidate version information shall be used as the target version information.

11. The version matching method according to claim 10, characterized in that, After matching the development environment version information with the reference environment version information, the process further includes: If the candidate version information is determined to be incompatible with the development environment version information based on the matching results, a version rollback is performed on the current running environment to make the current running environment compatible with the lightweight program.

12. The version matching method according to claim 5 or 10, characterized in that, The version matching method also includes: Based on the target version information, request configuration data from the configuration server to configure the current operating environment.

13. The version matching method according to claim 12, characterized in that, After requesting configuration data from the configuration server based on the target version information to configure the current operating environment, the method further includes: If the request for configuration data fails, a version rollback is performed on the current runtime environment to ensure that the current runtime environment is compatible with the lightweight program.

14. The version matching method according to claim 1, characterized in that, The development environment version information is generated in the following way: Obtain the development version information corresponding to the runtime environment that forms the basis for the development of the lightweight program; The development version information, or the version range determined based on the development version information, is added to the configuration file of the lightweight program as development environment version information.

15. The version matching method according to any one of claims 1-3 and 5-11, characterized in that, The matching is performed in the following manner: The development environment version information and the reference environment version information are respectively converted into a structured form to obtain a development structured object and a reference structured object; The developed structured object and the reference structured object are matched according to their corresponding fields. If all target fields meet the preset compatibility rules, the matching result is determined to be compatible.

16. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device configured to store one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the version matching method of any one of claims 1-15.

17. A non-volatile storage medium for storing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a processor, are configured to perform the version matching method of any one of claims 1-15.

Images