Real-time version rollback

The real-time rollback process for web-based applications addresses the inefficiencies of traditional update methods by enabling quick and secure reversion to a previously approved version, ensuring rapid issue resolution and user satisfaction.

JP2026523122APending Publication Date: 2026-07-13GOOGLE LLC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025564397
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-06-28
Filing Date
2024-06-28
Publication Date
2026-07-13

Smart Images

  • Figure 2026523122000001_ABST
    Figure 2026523122000001_ABST
Patent Text Reader

Abstract

A disclosed embodiment for rolling back a web-based application to a previous version. In response to receiving an intention to roll back a web-based application, a previous version of the web-based application that satisfies the rollback conditions is identified. Based on the previous version of the web-based application, a next version of the web-based application is generated. The next version of the web-based application is published to complete the rollback of the web-based application.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 510,801, filed Jun. 28, 2023, the disclosure of which is incorporated herein by reference in its entirety.

Background Art

[0002] Web - based (e.g., browser - based) applications are software programs stored on a remote server and using web - based technologies to deliver one or more functions to an end - user via a network through a browser client.

Summary of the Invention

[0003] Web-based applications (including extensions and other browser-based applications) combine the accessibility of web applications with the user-centered design of mobile apps. Web-based applications contain code or data that is downloaded and installed on the user's device, and are generally designed to function effectively on mobile devices while also being delivered via a web browser. These applications are typically offered through online application repositories, often called web stores or app stores, and can be modified by updates that create new versions of the application. Therefore, web-based applications are an example of items managed by iterative versioning. Current approaches to publishing new or updated versions typically involve several days of review before publication. At least one technical problem with this approach is that if problems or defects are discovered after publication (release), fixing these issues is difficult and time-consuming, as updated versions and / or rollbacks addressing these issues must also be approved through a multi-day review process to ensure the version meets repository guidelines.

[0004] The embodiments described herein provide at least one technical solution to these technical problems by providing a process for quickly and securely rolling back to a previously published version of a web-based application without requiring review and without altering the installation process used in browser applications. The embodiments generate a new version using an existing (e.g., previously published) version of a web-based application and a new version number, effectively making the existing application the new current version. In one exemplary embodiment, the rollback function is enabled by replacing publication information (e.g., version number) and ensuring that the deployed content is otherwise identical to a previously approved and scrutinized version of the application. The embodiments may also verify information (e.g., signature) related to the current proposal and / or developer of the current proposal of the web-based application against a previous proposal. The embodiments ensure that a new version is generated from a previously approved and deployed version, so that developers can quickly redeploy without review.

[0005] It will be understood that the methods provided herein may include any combination of the embodiments and features described herein. That is, the methods provided herein may include any combination of embodiments and features provided herein, and are not limited to the combinations of embodiments and features specifically described herein.

[0006] Therefore, in one example, the method includes, in response to receiving an intention to roll back a web-based application, identifying a previous version of the web-based application that satisfies the rollback conditions, generating a next version of the web-based application based on the previous version of the web-based application, and publishing the next version of the web-based application to complete the rollback of the web-based application.

[0007] Details of one or more embodiments of this disclosure are described in the accompanying drawings and the following description. Other features and advantages of this disclosure will become apparent from the description and drawings, as well as from the claims.

[0008] The following detailed description, along with the attached drawings, illustrates the aspects of the subject. [Brief explanation of the drawing]

[0009] [Figure 1A] This figure shows an exemplary user interface for receiving a rollback intention, according to several embodiments. [Figure 1B] This figure shows an exemplary user interface for receiving a rollback intention, according to several embodiments. [Figure 2A] This figure shows an exemplary user interface for receiving a version number and rollback display, according to several embodiments. [Figure 2B] This figure shows an exemplary user interface for receiving a version number and rollback display, according to several embodiments. [Figure 3] This figure shows a user interface for confirming rollback intent in various embodiments. [Figure 4A] This figure shows an exemplary architecture that can be used to carry out embodiments of the present disclosure. [Figure 4B] This figure shows an exemplary environment that can be used to carry out embodiments of the present disclosure. [Figure 5] This figure shows a flowchart of a non-limiting process that can be performed by embodiments of the present disclosure. [Figure 6] This figure shows an exemplary system including a computer or computing device that can be programmed or otherwise configured to implement the system or method of this disclosure. [Modes for carrying out the invention]

[0010] This disclosure relates to rolling back changes to items managed by iterative versioning, such as applications, in a fast and secure manner. The rollback system described may be implemented within a platform that provides an online item repository, where iterative versions of items are submitted and reviewed before being published for download and use, e.g., installation. Items are managed as they pass a review process carried out by the platform before they become available on the platform for public use. An example of such managed items available on a platform is a software marketplace, which provides an online application repository where iterative versions of applications are submitted for review before publication. Publication makes the item available for public use, e.g., application publication makes the application available for download and installation. The following description describes the rollback system in the context of a platform that provides web-based applications. However, the embodiments may be used in any platform that provides the submission of items for review before publication and the iterative versioning of items. Iterative versioning refers to version numbers that move in one direction, e.g., always increasing or always decreasing. For example, with iterative versioning, an item will always be assigned a higher (larger) version number to its next version compared to its current version. Decreasing iterative versioning can also be used. In other words, with iterative versioning, the version number assigned to the next version of an item moves in one direction.Examples of items managed by iterative versioning include game applications, customized models (e.g., language models), web-based applications such as browser-based applications (e.g., extensions and plugins), platform-managed websites, or any other submitted items that utilize iterative versioning, and items will be reviewed before publication.

[0011] In some cases, web-based applications work in conjunction with a browser to provide functionality to the user. Web-based applications contain code or data that is downloaded and installed on the user's device. Managed items, including web-based applications, may be provided through online item repositories, such as application repositories. Application repositories currently provide web-based applications for installation on the user's device. To ensure quality and security, stores may require web-based applications to be hosted and reviewed in the store before publication (i.e., before they become available to users). This review ensures that the extension complies with repository guidelines and typically takes several days (e.g., 3-4 business days).

[0012] Developers of web-based applications may occasionally develop new versions of their applications (for example, to fix bugs or add new features). This specification also applies to updates to web-based applications referred to as new application versions or simply "new versions," ensuring that the new application version complies with the store's guidelines. The application repository is not required to publish the new application version until this review is complete. Once a web-based application is published, the new application version becomes available for download in a browser. Therefore, it can take several business days from the time a new version of a web-based application is submitted to the online application repository (web store) until it is published by the application repository.

[0013] Browsers can periodically check the current or running version against the versions available in the application repository. If the current version is outdated, the browser can be configured to automatically download and install a newer version of the application (without user intervention). At least one technical problem with this approach is that, often, once the latest version is installed, the browser cannot be rolled back to the previous version. However, sometimes errors can occur with application updates that may not be detected until several browsers install the updated version. This error can "break" the web-based application and potentially other applications that work with it, causing users to uninstall the application and / or become distrustful of it. Currently, if a developer discovers a problem with an updated web-based application after its rollout (i.e., after publication and after browsers have started automatically installing updated versions), there is no way to quickly fix those problems without going through several days of review. In other words, older versions have to be (re)submitted for a multi-day review process, and as mentioned above, since browsers cannot roll back to previous version numbers, developers cannot quickly (e.g., in real time) revert updates.

[0014] As a technical solution to this problem, the disclosed embodiment provides a system for identifying previously tested and approved versions of a web-based application and immediately authorizing and publishing those versions (in real time) when rollout conditions are met. The embodiment minimizes the impact of incorrect or error-prone deployments, unexpected errors, and functional corruption caused by web-based applications.

[0015] The disclosed embodiments provide a real-time, secure “rollback” process for reverting updates to web-based applications and operate within the existing browser update process. In some embodiments, the rollback process allows developers to skip review processes (e.g., reviews spanning several days). In some embodiments, the redeployed version of the web-based application is not subject to manual review. As used herein, the term “real-time” means transmitting or processing data without intentional delay, taking into account the processing limits of the system, the time required to accurately retrieve data and images, and the rate of change of data and images. In some examples, “real-time” is used to describe the presentation of information obtained from components of the embodiments of this disclosure.

[0016] Some embodiments provide a rollback process via a developer dashboard. In some embodiments, the dashboard is a user interface provided by the application repository and used by application developers to add web-based applications to the store, update those applications, and roll back (e.g., redeploy) web-based applications to a selected (e.g., the last known available) version. In some cases, the last known available version refers to a previous version of the web-based application that was successfully published with the same visibility settings as the current configuration. The dashboard user interface may include selectable controls used to indicate the intention to roll back.

[0017] In some embodiments, the dashboard interface provides functionality for identifying the intention to roll back to a previous version and an interface for bringing the rollback to fruition. In some embodiments, the developer can provide a new version number for the previous version. The new version number allows the browser to automatically identify the rollback as the current version and install it. In other words, the embodiments can automatically repackage the developer's existing extension with the new version number, effectively making that existing extension the new current version. The embodiments may include automated detection of rollback submissions by checking the signature of the current submission against the previous submission.

[0018] Figure 1A shows an exemplary user interface for receiving a rollback intent, according to several embodiments. In the exemplary user interface 110a of Figure 1A, the user interface is for uploading a new package. A developer may navigate to user interface 110a to quickly upload a previous version after realizing that there is an error in the current version of a web-based application (e.g., a browser-based application). In some embodiments, if the conditions for rollback are met, user interface 110a may include a rollback intent control 120a. The rollback intent control 120a may be configured to surface a rollback user interface (e.g., in Figure 2A or 2B) in response to being selected. In some embodiments, if the conditions for rollback are not met, user interface 110a may not include a rollback intent control 120a.

[0019] Figure 1B is a diagram showing an exemplary user interface for receiving rollback intent according to some embodiments. In the exemplary user interface 110b of Figure 1B, the user interface is a user interface for updating a list of online application repositories. In the example of Figure 1B, the user interface 110b includes rollback intent control 120b as part of the menu options. In some embodiments, when the rollback condition is met, the user interface 110b can include the rollback intent control 120b when the user selects the three-dot menu 115.

[0020] The rollback intent control 120b can be configured to surface a rollback user interface (e.g., of Figure 2A or 2B) in response to being selected. In some embodiments, when the rollback condition is not met, the user interface 110b may not include the rollback intent control 120b. The rollback condition may not be met, for example, when there is no previous version, when the parameters associated with the previous version are set to a specific value (e.g., when visibility is set to "hidden" or when visibility has been changed from the initial setting), when the current version is a rollback version (i.e., there may be cases where developers are not permitted to continuously release rollback versions), when the application is identified (e.g., marked or flagged) based on the release guidelines, when the current version has not been fully deployed or rolled out, etc.

[0021] Figure 2A shows an exemplary user interface 200a for receiving version numbers and rollback notifications in several embodiments. User interface 200a is an example of a rollback user interface. In the example in Figure 2A, user interface 200a includes a version identifier control 220a. The version identifier control 220a may be a text box that allows a developer to enter a previous version number of the web-based application to be used for rollback. In such embodiments, the system can check the version number entered using the version identifier control 220a for one or more rollback conditions. In some embodiments, the system can verify that the version number provided by the developer (in the version identifier control 220a) is higher (i.e., later) than the current version number of the web-based application.

[0022] In some embodiments, the user interface 200a may include rollback display control such as a rollback display text box 230. The rollback display text box 230 is a text box used to capture the reason for the rollback. In some embodiments, the rollback depends on what is entered in the rollback display text box 230. In other words, the user interface 200a may not allow the developer to perform a rollback until some text is entered in the rollback display text box 230. In such embodiments, the control 240 may not be selectable until text is entered in the rollback display text box 230. In some embodiments, entering text in the rollback display text box 230 is optional. In some embodiments, the content of the rollback display text box 230 is used to identify a new version number as a rollback version (e.g., in a data store such as the app version data store 428 described below with reference to FIG. 4A). In some embodiments, the system can add a flag, tag, or other indication that the version number is a rollback version (e.g., in the app version data store 428) after the control 240 is selected.

[0023] Figure 2B shows an exemplary user interface 200b for receiving version number and rollback notifications in several embodiments. User interface 200b is an example of a rollback user interface. In the example of Figure 2B, user interface 200b may provide a version identifier control 220b. The version identifier control 220b is a dropdown selection control. The dropdown selection control may be configured to display the current version and previous versions of a web-based application. The system may include a data store for the current and previous versions (e.g., an app version data store 428). The version identifier control 220b allows the developer to select a version to use as a rollback. In some embodiments, only versions that satisfy the rollback conditions (or more conditions) are presented as selectable options in the version identifier control, e.g., a menu option 225.

[0024] Figure 3 shows a user interface 300 for confirming a rollback intention in various embodiments. For example, the user interface 300 may be presented to the user in response to all rollback conditions being met and the user selecting control 240. In some embodiments, the developer provides confirmation to initiate a rollback based on the selected previous version by selecting a confirmation button 302. In some embodiments, based on the confirmation provided in the user interface 300, the system is configured to generate and publish a new rollback version (rollback version). In some embodiments, the system may be configured to bypass user confirmation and generate and publish a new rollback version without confirmation by the developer.

[0025] Figure 4A shows an exemplary architecture 400 that can be used to carry out embodiments of the present disclosure. The exemplary architecture 400 includes a communication network 410, an application repository server 420, a client device 430, and a developer device 440. The communication network 410 is a group of nodes interconnected by links used to exchange messages between nodes. The links may carry messages and signals using various techniques based on circuit switching, message switching, or packet switching methodologies. The communication network 410 connects (e.g., communicatively coupled) the application repository server 420, the client device 430, and the developer device 440. The communication network 410 may include a telecommunications or data network, which will be described in more detail later with reference to Figure 4B. In some embodiments, the client device 430 and the developer device are persistently similar to the computing device 610, which will be described later with reference to Figure 6.

[0026] Users of client device 430 interact with applications 432, such as a graphical user interface (GUI) (e.g., user interface 625, described below with reference to Figure 6) or client applications installed and running on client device 430. An exemplary client application includes a browser 434 (i.e., a browser application). In some embodiments, the browser 434 is configured to communicate with other computing devices (e.g., a web server) via a communication network 410 to fetch and render content (e.g., web-based content). In some embodiments, the browser 434 provides content via a display with which the user can interact. For example, the browser 434 may be configured to display web pages, run web applications, etc.

[0027] In some embodiments, the browser 434 receives content by loading a native library, performing a Domain Name System (DNS) lookup based on a resource locator (e.g., a Uniform Resource Locator (URL)) associated with a specific resource (e.g., a web service provided via a web server), and downloading the provided content. In some embodiments, the browser 434 includes a renderer for providing the received content to the user. For example, the browser 434 may be configured to provide content via browser tabs in a browser window, which may include user interfaces such as 110a, 110b, 200a, 200b, and 300, as described above with reference to Figures 1A, 1B, 2A, 2B, and 3, respectively.

[0028] The use of browser 434 allows resources (such as web-based content) to provide navigation bars, sitemaps, dropdown menus, etc., for navigating resources within a domain. In some embodiments, browser 434 includes tools to support navigation, such as bookmarks and browsing history. In some embodiments, browser 434 defines forward and back buttons for navigating through previously viewed resources (e.g., web pages). In some embodiments, the client device 430 is a mobile device, and browser 434 is a mobile browser designed for use on a mobile device. In such embodiments, browser 434 is configured to render and display web-based content in a mobile format (in addition to a desktop format).

[0029] The browser 434 may include additional functionality in the form of a web-based application, such as a browser-based application 436 (e.g., an extension). In some embodiments, the browser 434 is configured to check for version updates to the browser-based application 436. For example, the browser 434 may be configured to communicate with an application repository server 420 (provided via a backend system such as the backend system 480 described below with reference to Figure 4B) to determine if a new version of the browser-based application 436 is available for download. If a newer version is identified, the browser 434 can download and install the updated version (e.g., via the repository interface 426). In some embodiments, the browser 434 is configured to periodically check for updates to the browser-based application 436.

[0030] As shown in Figure 4A, the app repository server 420 includes a dashboard module 422. In some embodiments, the dashboard module 422 is an application or service configured to assist a developer (e.g., a user in an embodiment of a developer device 440) in managing a browser-based application 436 stored in the app version data store 428. In some embodiments, once stored in the app version data store 428, the app repository server 420 is configured to provide a new version of the browser-based application 436 to an embodiment of a browser 434 running via an embodiment of a client device 430. In some cases, the developer uses the developer device 440 to communicate with the app repository server 420 via the communication network 410 and provides the code for downloading (e.g., a new and / or updated version) and installing the browser-based application 436 via the dashboard module 422. In some cases, the developer device 440 is configured to provide the browser-based application 436 via the dashboard module 422 using known techniques such as compressed files, compressed files with special headers (e.g., packages). In some embodiments, the dashboard module 422 provides a package interface (e.g., user interface 110a in Figure 1A) used to upload new packages / compressed files. In some embodiments, the dashboard module 422 provides a store interface (e.g., user interface 110b in Figure 1B) for managing and / or displaying metadata about browser-based applications such as browser-based application 436.

[0031] In some embodiments, the dashboard module 422 includes a rollback verifier module 424. In some embodiments, the rollback verifier module 424 allows a developer (e.g., via a developer device 440) to identify previous versions of a browser-based application 436 stored in the app version data store 428, update the version number of the identified previous version, and immediately publish the new version (e.g., store the updated version in the app version data store 428 and identify it as the latest version of the browser-based application 436) when one or more rollback conditions are met. In some cases, determining that the rollback conditions are met involves evaluating the status of the previous version of the browser-based application 436. By publishing, the new version becomes available for download and installation by the browser 434 via the repository interface 426. The user interfaces 200a, 200b, and 300 shown in Figures 2A, 2B, and 3, respectively, represent user interfaces that may be generated by the dashboard module 422 and / or the rollback verifier module 424.

[0032] The app version data store 428 is implemented via a data store such as data store 484, which is described below with reference to Figure 4B. Examples of items in the app version data store 428 include installable items, such as browser extensions, mobile applications, native applications, and progressive web applications. The app version data store 428 may be searchable by a limited number of text fields (for example, via a provided repository interface 426). For example, items in the app version data store 428 may be indexed by terms such as item description, item title, other identifiers, and terms in the manifest file. As described above, an embodiment of the client device 430 may be configured to search for and download a browser-based application 436 via the repository interface 426 after it has been uploaded via the developer device 440 via the dashboard module 422.

[0033] Figure 4B shows an exemplary environment 450 that can be used to carry out embodiments of the present disclosure. The exemplary environment 450 includes computing devices 462, 464, 466, 468, a backend system 480, and a communication network 410. As described above, the communication network 410 is a group of nodes interconnected by links used to exchange messages between nodes. The communication network 410 may include a wireless portion and a wired portion. In some cases, the communication network 410 is carried out using one or more existing networks, such as a cellular network, the Internet, a land mobile radio (LMR) network, a Bluetooth® network, a wireless local area network (e.g., Wi-Fi), a wireless accessory personal area network (PAN), a machine-to-machine (M2M) network, and a telephone network.

[0034] In some embodiments, the communication network 410 includes the Internet, an intranet, an extranet, or an intranet and / or extranet communicating with the Internet. The communication network 410 may include a telecommunications network or a data network, and networks to be developed in the future. In some embodiments, the communication network 410 connects a website, devices (e.g., computing devices 462, 464, 466, and 468), and a backend system (e.g., a backend system 480). In some examples, the network 410 can be accessed via wired and / or wireless communication links. For example, mobile computing devices (e.g., smartphone device 462 and tablet device 466) can access the communication network 410 using a cellular network.

[0035] In some embodiments, computing devices 462, 464, 466, and 468 are persistently similar to computing device 610, which is described below with reference to Figure 6. In some embodiments, each of computing devices 462, 464, 466, and 468 may be used as one or more of the client devices 430 or developer devices 440 described above with reference to Figure 4A. For example, the same computing devices 462, 464, 466, and 468 may be used as both a developer device 440 (e.g., for generating / uploading a new version of a browser-based application 436) and a client device 430 (e.g., for testing whether a browser 434 updates the browser-based application 436 to a new version). Computing devices 462, 464, 466, and 468 may include any suitable type of computing device, such as desktop computers, laptop computers, handheld computers, tablet computers, personal digital assistants (PDAs), XR / AR / VR devices, mobile phones, network appliances, cameras, smartphones, Enhanced General Packet Radio Services (EGPRS) mobile phones, media players, navigation devices, email devices, game consoles, or any two or more suitable combinations of these or other data processing devices (for example, each may include).

[0036] Four user computing devices 462, 464, 466, and 468 are shown in Figure 4B for simplicity. In the exemplary environment 450 shown, computing device 462 is shown as a smartphone, computing device 464 as a tablet computing device, computing device 466 as a desktop computing device, and computing device 468 as an XR device. However, embodiments of the present disclosure are intended to be implemented using any of the appropriate computing devices as described above. Furthermore, embodiments of the present disclosure can use any number of devices.

[0037] In some embodiments, the backend system 480 includes at least one server device 482 and optionally at least one datastore 484. In some embodiments, the server device 482 is persistently similar to the computing device 610 described below with reference to Figure 6. In some embodiments, the server device 482 is a server-class hardware type device. In some embodiments, the backend system 480 includes a computer system that uses clustered computers and components to function as a single pool of seamless resources when accessed over a communication network 410. For example, such embodiments may be used in data center, cloud computing, storage area network (SAN), and network-attached storage (NAS) applications. In some embodiments, the backend system 480 is deployed using virtual machines.

[0038] In some embodiments, the backend system 480 hosts one or more computer implementation services that users 472, 474, 476, and 478 can interact with using their respective computing devices 462, 464, 466, and 468. For example, in some embodiments, the backend system 480 is configured as an application repository server 420 (described above with reference to Figure 4A) to implement the concepts described herein.

[0039] In some embodiments, datastore 484 is a repository for persistently storing and managing a collection of data (e.g., versions of web-based applications such as browser-based application 436). Exemplary datastores that may be used within the described system include data repositories such as databases, as well as simpler store types such as files and emails. In some embodiments, datastore 484 includes a database. In some embodiments, a database is an organized collection of bytes or data managed by a database management system (DBMS). Embodiments of the application version datastore 428 may be provided via datastore 484, as described above with reference to Figure 4A.

[0040] Figure 5 is a flowchart of an exemplary process 500 that can be performed by embodiments of the present disclosure. The exemplary process 500 can be performed by the systems and components described with reference to Figures 1A-4 and 6. The exemplary process 500 more specifically illustrates various embodiments for rolling back a web-based application to a previous version and creating an updated previous version for download and installation on a device (e.g., a client device 430) via an application repository dashboard, which is generally run on an application repository server (e.g., provided via a backend system 480).

[0041] For clarity, the following description generally illustrates process 500 in the context of Figures 1A-4B and 6. However, it will be understood that process 500 may be performed, for example, by any other suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware, as needed. In some embodiments, the various operations of process 500 may be performed in parallel, in combination, in loops, or in any order.

[0042] In 502, the intention to roll back a web-based application, such as a browser-based application, is received via a user interface (for example, user interfaces 100a or 100b described above, with reference to Figures 1A and 1B, respectively). In some cases, the intention is determined by an explicit intention. For example, a selection of a rollback intention control, such as rollback intention control 120a or rollback intention control 120b, may be received. In some cases, the intention is implicit. An implicit intention may be determined through a comparison of newly uploaded packages. In some cases, it is detected whether a newly uploaded package has the same signature as a previously uploaded package.

[0043] From 502, process 500 proceeds to 504, where previous versions of the web-based application are identified. In some embodiments, previous versions are identified by retrieving all historical versions of the web-based application (stored in a data store, such as the app version data store 428, for example, as described below with reference to Figure 4A). In some embodiments, historical versions are filtered based on rollback conditions (i.e., versions are excluded or included based on whether they meet or do not meet rollback conditions). For example, a version may be excluded if it is a currently published version, or if it has never been published or has not been published to a threshold number / percentage of browsers.

[0044] In some embodiments, the rollback condition includes determining that the current version of the web-based application is not a rollback version. In some embodiments, the rollback condition includes determining that a parameter associated with the current version has not been changed to a state that disables rollback. For example, a visibility parameter, which indicates whether the web-based application is accessible (e.g., downloadable), is set to a hidden or inactive state. In some embodiments, the rollback condition includes determining that the web-based application is missing an identified violation. Violations include defects in the web-enabled application and / or failure of the developer associated with the web-enabled application to meet repository guidelines. For example, the rollback condition may not be met when the web-based application is identified (marked / flagged) as subject to a violation (e.g., if the application does not meet the repository guidelines, the web-based application is assigned / associated with a guideline violation). In some embodiments, the previous version is associated with a first visibility parameter. In some embodiments, the rollback condition includes determining that the first visibility parameter matches a second visibility parameter associated with the current version of the web-based application. For example, both the current version and previous versions are set to visibility that allows for downloading the web-based application.

[0045] In some embodiments, a rollback user interface is provided in response to a determination that an intention to roll back a web-based application has been received / occurred. In some cases, the rollback user interface collects the version number of the web-based application to be used as the new version. In some embodiments, a filtered list of versions is presented to the user (for example, via user interfaces 200a and / or 200b described above with reference to Figures 2A and 2B respectively, which are provided via dashboard module 422 as described above with reference to Figure 4A), and the user identifies (i.e., selects) the previous version from the filtered list. In some embodiments, the previous version is automatically identified by selecting the version from the filtered list having the highest version and / or revision identifier (or based on some other metadata and / or criteria). In some embodiments, the display settings of the identified previous version are verified to be the same as the current version and / or that the display settings have not changed between the two versions.

[0046] In some embodiments, rollback conditions are determined and measured against a threshold. In some embodiments, if there are multiple rollback conditions that need to be met, one or more of these rollback conditions may be validated (e.g., as a previous backstop enabling automatic publication of a previous version as an updated version). In some embodiments, the user is provided with an indication (e.g., an error message) (via dashboard module 422) that the rollback conditions(s) are not met if there is no previous version of the web-based application that satisfies the rollback conditions(s). In some embodiments, the indication may be provided to the user via a user interface such as user interfaces 200a and 200b described above with reference to Figures 2A and 2B, which allows the developer to modify the data (e.g., provide a valid version number and / or rollback indication).

[0047] From 504, process 500 proceeds to 506, where the next version of the web-based application is generated based on a previous version of the web-based application. In some embodiments, the next version includes a new version number. In some embodiments, the new version number may be any number that causes a browser application (e.g., browser 434) running on a device (e.g., client device 430) to recognize that an update has been made to the web-based application (e.g., web-based application 436) and / or to recognize the need to download and install a newer version of the web-based application.

[0048] In some embodiments, the next version of a web-based application is generated by extracting code files (e.g., at least one) from a first archive file associated with a previous version of the web-based application. An archive file is a computer file consisting of one or more files (e.g., code files) along with metadata. Archive files may be used to facilitate portability and preservation, and / or to compress files to reduce storage space. Archive files may store directory structures, error detection and correction information, and comments. Archive files may be stored in specific archive formats that support member file compression. Exemplary archive formats include ZIP, Roshal Archive (RAR), Tape Archive (TAR), and 7Z Archive.

[0049] In some embodiments, code files (e.g., JSON files) extracted from the first archive file are updated with the new version number. In some embodiments, the version field is updated, but the package version name field is not. To avoid confusing developers, the version name is retained so that both developers and users can see which package the application is rolling back to. For example, if the application is rolled back from version 1.4 to 1.3 (version names are Ext 1.4'' and Ext 1.3'' respectively), the user will see Ext 1.3'' as the version label after the rollback, which accurately reflects which package is installed. In some cases, the version field is updated so that the browser properly receives the update.

[0050] Code files generally contain instructions that a device (e.g., client device 430) executes to perform a specific task or solve a problem (e.g., a function of the respective web-based application), and / or content associated with performing that specific task or solving the problem. Examples of file types that may be included in a web-based application archive include, but are not limited to, Java Script Object Notation (JSON) files and Hypertext Markup Language (HTML) files, and include content of the web-based application such as scripts (e.g., event scripts, content scripts), image links, sidebars, popups, options pages, and web-accessible resources.

[0051] In some embodiments, at least one updated code file is compressed into a second archive file. In some embodiments, a digital signature is generated based on the second archive file. In some embodiments, the digital signature is generated by processing the second archive file and a private key associated with the web-based application through a signature algorithm to generate a digital signature. In some cases, the private key is a cryptographic key that can be used to create the digital signature. The signature algorithm is a cryptographic algorithm used to generate the digital signature, authenticate the sender of the digital message, and prevent tampering with the message. Examples of signature algorithms include the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), etc. In some cases, the digital signature is verified when the respective version of the web-based application is downloaded (e.g., by browser 434 and / or repository interface 426).

[0052] In some embodiments, the next version of the web-based application is generated based on a second archive file and a digital signature. In some embodiments, the next version of the web-based application is generated using a dedicated thread pool (i.e., one or more threads dedicated to generating the next version of the web-based application from the previous version).

[0053] From 506, process 500 proceeds to 508, in which the next version of the web-based application is published to complete the rollback of the web-based application. In some embodiments, publishing the next version of the web-based application further includes providing version data associated with the web-based application to the user interface. In some embodiments, confirmation of the version data is received from the user interface. In some embodiments, the version data includes a new version number, a current version number associated with the current version of the web-based application, and a previous version number associated with a previous version. In some embodiments, based on the confirmation, the next version of the web-based application is published (i.e., made downloadable).

[0054] In some embodiments, the current version of a web-based application is identified before publishing the next version of the web-based application. In some embodiments, after publishing the next version of the web-based application, the current version of the web-based application is archived in a repository (e.g., app version data store 428) by associating the current version with an archived or inactive state. In some embodiments, a rollback indicator of the web-based application is obtained (e.g., when a new version is published). In some cases, the rollback indicator is a flag that is not collected from the developer. In some cases, the rollback indicator is provided by the developer via a dashboard. In some cases, the indicator may include justification or explanation for the rollback. In some embodiments, the indicator is stored in the repository (e.g., app version data store 428) along with the new version number and previous version of the web-based application. From 508, process 500 terminates or is repeated.

[0055] Figure 6 shows an exemplary computing system 600, which includes a computer or computing device 610 that can be programmed or otherwise configured to implement the system or method of the present disclosure. For example, the computing device 610 can be programmed or configured to perform the process 500 described above with reference to Figure 5.

[0056] In the illustrated embodiments, the computer or computing device 610 includes an electronic processor (also referred to herein as “processor” and “computer processor”) 612, such as a central processing unit (CPU), a tensor processing unit (TPU), or a graphics processing processor (GPU), which may optionally be a single-core, multi-core, or multiple processors for parallel processing. The illustrated embodiments also include memory 617 (e.g., random-access memory, read-only memory, flash memory), electronic storage device 614 (e.g., hard disk or flash), a communication interface module 615 for communicating with one or more other systems (e.g., a network adapter or modem), and peripheral devices 616 such as cache, other memory, data storage, microphone, and speaker. In some embodiments, the memory 617, electronic storage device 614, communication interface module 615, and peripheral devices 616 communicate with the electronic processor 612 via a communication bus (shown by solid lines), such as a motherboard. In some embodiments, the bus of the computing device 610 includes multiple buses. In some embodiments, the computing device 610 includes more or fewer components than those shown in Figure 6 and performs functions other than those described herein.

[0057] In some embodiments, the memory 617 and the electronic storage device 614 include one or more physical devices used for temporary or permanent storage of data or programs. In some embodiments, the memory 617 is volatile memory and can use power to maintain the stored information. In some embodiments, the electronic storage device 614 is non-volatile memory and retains the stored information when the computer is not powered on. In further embodiments, the memory 617 or the electronic storage device 614 is a combination of devices as disclosed herein. In some embodiments, the memory 617 or the electronic storage device 614 may be distributed across multiple machines, such as network-based memory or memory in multiple machines running the computing device 610.

[0058] In some cases, the electronic storage device 614 is a data storage device or data store for storing data. In some cases, the electronic storage device 614 stores files such as drivers, libraries, and saved programs. In some embodiments, the electronic storage device 614 stores data received by the device. In some embodiments, the computing device 610 includes one or more external additional data storage devices, such as those located on a remote server that communicates over a network (e.g., the communication network 410 described above with respect to Figures 4A and 4B).

[0059] In some embodiments, the platforms, systems, media, and methods described herein are executed by machine or computer-executable code stored in an electronic storage location (e.g., a non-temporary computer-readable storage medium) of a computing device 610, such as in memory 617 or electronic storage device 614. In further embodiments, the computer-readable storage medium is optionally removable from the computer. Non-limiting examples of computer-readable storage media include compact disk read-only memory (CD-ROM), digital versatile disk (DVD), flash memory devices, solid-state memory, magnetic disk drives, magnetic tape drives, optical disk drives, cloud computing systems and services, and the like. In some cases, the computer-executable code is encoded on the medium permanently, substantially permanently, semi-permanently, or non-temporarily.

[0060] In some embodiments, the electronic processor 612 is configured to execute code. In some embodiments, machine-executable code or machine-readable code is provided in software form. In some examples, the code is executed by the electronic processor 612 while in use. In some cases, the code is retrieved from the electronic storage device 614 and stored in memory 617 for immediate access by the electronic processor 612. In some situations, the electronic storage device 614 is removed and the machine-executable instructions are stored in memory 617.

[0061] In some cases, the electronic processor 612 is a component of a circuit, such as an integrated circuit. One or more other components of the computing device 610 may optionally be included in the circuit. In some cases, the circuit is an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). In some cases, the operation of the electronic processor 612 can be distributed across multiple machines (each machine may have one or more processors) that can be coupled directly or via a communication network (e.g., the communication network 410 described above with reference to Figures 4A and 4B).

[0062] In some cases, the computing device 610 may be optionally coupled to a communication network, such as the communication network 410 described above with reference to Figures 4A and 4B, via a communication interface module 615 which may include digital signal processing circuitry. The communication interface module 615 may provide communication in various modes or protocols, such as Global System for Mobile (GSM®) voice calls, Short Message / Messaging Service (SMS), Extended Messaging Service (EMS), or Multimedia Messaging Service (MMS) messaging, Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Wideband Code Division Multiple Access (WCDMA®), CDMA2000, or General Purpose Packet Radio Service (GPRS). Such communication may be performed, for example, via transceivers. Additionally, short-range communication may be performed, for example, using Bluetooth, Wi-Fi, or other such transceivers.

[0063] In some cases, the computing device 610 includes an operating system 640 configured to execute executable instructions. The operating system is software that includes programs and data that manage hardware (e.g., an electronic processor 612, memory 617, electronic storage device 614, communication interface module 615, peripheral devices 616, and memory 617) and provide services for the execution of one or more applications 642. An application is a set of instructions stored in memory (e.g., memory 617) that are executable by the electronic processor (e.g., electronic processor 612) to perform operations. The aforementioned hardware components of the computing device 610 can be used to facilitate the operation of the operating system 640 and one or more applications 642 that are executed through the operating system 640.

[0064] In some cases, computing device 610 is a personal computing device (or user computing device) such as computing devices 462, 464, 466, and 468 described above with reference to Figure 4A. In some cases, the personal computing device is configured as a client device 430 and / or developer device 440 (described above with reference to Figure 4A) to provide the described embodiment of the system. In such cases, application 642 may include a browser application (e.g., browser 434). In some embodiments, the browser application is integrated into the operating system 640 (e.g., a browser-based operating system).

[0065] In some cases, the computing device 610 includes or communicates with one or more output devices 620. In some cases, the output devices 620 include a display for sending visual information to the user. In some cases, the output device 620 is a touch-sensitive display that combines a display with a touch-sensing element capable of operating to sense touch input and functionality as both an output device 620 and an input device 630. In further cases, the output device 620 is a combination of devices such as those disclosed herein. In some cases, the output device 620 displays a user interface 625 generated by the computing device 610 (for example, the user interfaces described above with reference to Figures 1A, 1B, 2A, 2B, and 3).

[0066] In some cases, the computing device 610 includes or communicates with one or more input devices 630 configured to receive information from a user. In some cases, the input device 630 is a keyboard. In some cases, the input device 630 is a keypad (e.g., a telephone-based keypad). In some cases, the input device 630 is a cursor control device, including, in non-limiting examples, a mouse, trackball, trackpad, joystick, game controller, or stylus. In some cases, as described above, the input device 630 is a touchscreen or multitouchscreen. In other cases, the input device 630 is a microphone for capturing voice or other audio input. In other cases, the input device 630 is an imaging device such as a camera. In further cases, the input device is a combination of devices such as those disclosed herein.

[0067] Furthermore, it should be noted that multiple hardware and software-based devices, as well as multiple different structural components, may be used to implement the examples described. Moreover, embodiments may include hardware, software, and electronic components or modules that, for illustrative purposes, are illustrated and described as if most of the components were implemented in hardware as a single unit. In some embodiments, the electronic-based aspects of this disclosure may be executed by software (e.g., stored in a non-temporary computer-readable medium) executable by one or more processors, such as the electronic processor 612. Therefore, it should be noted that multiple hardware and software-based devices, as well as multiple different structural components, may be used to implement various examples.

[0068] Furthermore, while certain drawings show hardware and software located within specific devices, it should be understood that these depictions are for illustrative purposes only. In some embodiments, the illustrated components may be combined or separated into separate software, firmware, or hardware. For example, instead of residing within and being executed by a single electronic processor, logic and processing may be distributed among multiple electronic processors. Regardless of how they are combined or separated, hardware and software components may reside on the same computing device or be distributed among different computing devices connected by one or more networks or other appropriate communication links.

[0069] Furthermore, various embodiments of the systems and technologies described herein can be realized in digital electronic circuits, integrated circuits, specially designed ASICs (application-specific integrated circuits), computer hardware, firmware, software, or combinations thereof. These various embodiments may include embodiments in one or more computer programs executable or interpretable on a programmable system, comprising at least one programmable processor, the at least one programmable processor may be dedicated or general-purpose, coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transmit data and instructions to them.

[0070] These computer programs (also known as programs, software, software applications, or code) contain instructions or machine instructions that a computer can take to a programmable electronic processor and can be implemented in a high-level procedural programming language, an object-oriented programming language, or an assembly / machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, apparatus, or device (e.g., magnetic disks, optical disks, memory, programmable logic circuits (PLDs)) used to provide machine instructions or data to a programmable processor, including machine-readable medium that receives machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions or data to a programmable processor.

[0071] The functionality of computer-readable instructions can be combined or distributed as desired in various environments. In some embodiments, a computer program includes a set of instructions. In some embodiments, a computer program includes multiple sets of instructions. In some embodiments, a computer program is provided from one location. In other embodiments, a computer program is provided from multiple locations. In various embodiments, a computer program includes one or more software modules. In various embodiments, a computer program includes, in part or in whole, one or more web applications, one or more mobile applications, one or more standalone applications, one or more web browser plugins, extensions, add-ins, or add-ons, or a combination thereof.

[0072] Unless otherwise defined, all technical terms used herein have the same meaning as those generally understood by those skilled in the art to which the present invention belongs. Where used herein and in the appended claims, the singular forms "a," "an," and "the" include plural referents unless otherwise clearly indicated by the context. Any reference to "or" herein is intended to include "and / or" unless otherwise specified.

[0073] Several embodiments are described. Needless to say, it will be understood that various modifications can be made without departing from the spirit and scope of the disclosed embodiments. While several embodiments of this disclosure are shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided only as examples. Therefore, those skilled in the art will anticipate numerous variations, modifications, and substitutions without departing from the described system. It should be understood that various alternatives to the embodiments described herein may be employed in the practice of the described system.

[0074] Furthermore, the separation or integration of various system modules and components in the embodiments described above should not be understood as requiring such separation or integration in all embodiments, and the components and systems described above should generally be understood as being able to be integrated into a single product or packaged into multiple products. Accordingly, the foregoing description of exemplary embodiments does not define or limit this disclosure. Other changes, substitutions, and modifications are possible without departing from the spirit and scope of this disclosure.

[0075] example The following paragraphs provide various examples of embodiments disclosed herein.

[0076] Example 1 is a method that, in response to receiving an intention to roll back a web-based application, includes identifying a previous version of the web-based application that satisfies the rollback conditions, generating a next version of the web-based application based on the previous version of the web-based application, and publishing the next version of the web-based application to complete the rollback of the web-based application.

[0077] Example 2 further includes generating the next version of the web-based application by extracting at least one code file from a first archive file associated with a previous version of the web-based application, and updating at least one code file with a new version number, which includes the subject matter of Example 1.

[0078] Example 3 further includes generating a next version of a web-based application by compressing at least one code file containing the subject matter of Example 1 or 2, which has been further updated, into a second archive file, generating a digital signature based on the second archive file, and generating the next version of the web-based application based on the second archive file and the digital signature.

[0079] Example 4 includes the subject matter of any one of Examples 1-3 and further comprises generating a digital signature by processing a second archive file and a private key associated with a web-based application through a signature algorithm to generate a digital signature.

[0080] Example 5 includes one of the subjects from Examples 1-4 and further specifies that the previous version is associated with the first visibility parameter.

[0081] Example 6 includes the subject matter of any one of Examples 1-5 and further specifies that the rollback condition is determined when a first visibility parameter matches a second visibility parameter associated with the current version of the web-based application.

[0082] Example 7 includes the subject of any one of Examples 1-6 and further specifies that the rollback condition is a first rollback condition, and the method further includes determining whether the current version of the web-based application satisfies a second rollback condition, which includes determining that the current version of the web-based application is not a rollback version.

[0083] Example 8 includes the subject matter of any of Examples 1-7, and further specifies that the rollback condition is a first rollback condition, and the method further includes determining whether the current version of the web-based application satisfies a second rollback condition, which includes determining that the visibility parameter associated with the current version has not been changed to a hidden or inactive state.

[0084] Example 9 includes the subject matter of any one of Examples 1-8 and further specifies that generating the next version of a web-based application includes generating a new version number for the web-based application, the new version number being a number that makes the client device aware that the web-based application has been updated.

[0085] Example 10 includes the subject matter of any one of Examples 1-9 and further specifies that the rollback condition includes determining that the web-based application is missing an identified violation.

[0086] Example 11 includes the subject matter of any one of Examples 1-10 and further includes providing an indication in the user interface that the rollback condition is such that a previous version of the web-based application does not meet the rollback condition.

[0087] Example 12 includes the subject of any one of Examples 1 to 11, and further includes publishing the next version of the web-based application by providing version data related to the web-based application in the user interface, receiving confirmation of the version data from the user interface, and publishing the next version of the web-based application based on the confirmation.

[0088] Example 13 includes the subject matter of any one of Examples 1 through 12 and further specifies that the version data includes the new version number, the current version number associated with the current version of the web-based application, and the previous version number associated with previous versions.

[0089] Example 14 includes the subject matter of any one of Examples 1-13 and further includes identifying the current version of a web-based application before publishing the next version of the web-based application, and after publishing the next version of the web-based application, archiving the current version of the web-based application in a repository by associating the current version with an archived or inactive state.

[0090] Example 15 includes the subject of any one of Examples 1-14 and further includes obtaining a rollback display of a web-based application and storing the display in a repository along with the new version number and the previous version of the web-based application.

[0091] Example 16 includes the subject matter of any one of Examples 1-15 and further specifies that the next version of the web-based application will be generated using a dedicated thread pool.

[0092] Example 17 includes one of the themes from Examples 1 through 16 and further specifies that the web-based application is a customized model.

[0093] Example 18 includes one of the themes from Examples 1 through 17, further defining the customized model as a language model.

[0094] Example 19 includes one of the subjects from Examples 1-18 and further specifies that the web-based application is managed.

[0095] Example 20 is a computer-readable medium that, when executed by an electronic processor, stores instructions that cause the electronic processor to perform the method described in any one of Examples 1-19.

[0096] Example 21 is a system that includes an electronic processor and a memory that is communicatively coupled to the electronic processor and stores instructions. When executed by the electronic processor, these instructions cause the system to receive an intention from the user interface to roll back a web-based application, identify a previous version of the web-based application that satisfies the rollback conditions, generate a next version of the web-based application based on the previous version of the web-based application, and publish the next version of the web-based application to complete the rollback of the web-based application.

[0097] Example 22 includes the subject matter of Example 21 and further specifies instructions that, when executed by an electronic processor, cause the system to generate further versions of the web-based application by extracting at least one code file from a first archive file associated with a previous version of the web-based application and updating at least one code file with a new version number.

[0098] Example 23 includes the subject matter of Example 21 or 22 and further specifies instructions that, when executed by an electronic processor, cause the system to generate further versions of the web-based application by compressing at least one updated code file into a second archive file, generating a digital signature based on the second archive file, and generating the next version of the web-based application based on the second archive file and the digital signature.

[0099] Example 24 includes the subject matter of any one of Examples 21-23 and further specifies instructions that, when executed by an electronic processor, cause the system to generate a digital signature by processing a second archive file and a private key associated with a web-based application through a signature algorithm to generate a digital signature.

[0100] Example 25 includes one of the subjects from Examples 21-24 and further specifies that the previous version is associated with the first visibility parameter.

[0101] Example 26 includes the subject matter of any one of Examples 21-25 and further specifies that the rollback condition is determined when a first visibility parameter matches a second visibility parameter related to the current version of the web-based application.

[0102] Example 27 includes the subject matter of any one of Examples 21-26, and further specifies that the rollback condition is a first rollback condition, and the instruction, when executed by the electronic processor, further causes the system to determine whether the current version of the web-based application satisfies a second rollback condition, which includes determining that the current version of the web-based application is not a rollback version.

[0103] Example 28 includes the subject matter of any one of Examples 21-27, and further specifies that the rollback condition is a first rollback condition, and the instruction, when executed by the electronic processor, further causes the system to determine whether the current version of the web-based application satisfies a second rollback condition, which includes determining that the visibility parameter associated with the current version has not been changed to a hidden or inactive state.

[0104] Example 29 includes the subject matter of any one of Examples 21-28 and further specifies that generating the next version of a web-based application includes generating a new version number for the web-based application, the new version number being a number that makes the client device aware that the web-based application has been updated.

[0105] Example 30 includes the subject matter of any one of Examples 21-29 and further specifies that the rollback condition includes determining that the web-based application is missing an identified violation.

[0106] Example 31 includes the subject matter of any one of Examples 21-30, and further specifies that, when executed by an electronic processor, the instruction causes the system to provide a display to the user interface indicating that the rollback conditions are not met, in response to the system determining that a previous version of a web-based application does not meet the rollback conditions.

[0107] Example 32 includes the subject matter of any one of Examples 21-31, and further specifies that when the instruction is executed by the electronic processor, the system will publish the next version of the web-based application, provide the user interface with version data related to the web-based application, receive confirmation of the version data from the user interface, and, based on the confirmation, publish the next version of the web-based application.

[0108] Example 33 includes the subject matter of any one of Examples 21-32 and further specifies that the version data includes the new version number, the current version number associated with the current version of the web-based application, and the previous version number associated with previous versions.

[0109] Example 34 includes the subject matter of any one of Examples 21-33, and further specifies that when executed by an electronic processor, the instruction will further cause the system to identify the current version of a web-based application before publishing the next version of the web-based application, and after publishing the next version of the web-based application, to archive the current version of the web-based application in a repository by associating the current version with an archived or inactive state.

[0110] Example 35 includes the subject matter of any one of Examples 21-34, and further specifies that when the instruction is executed by the electronic processor, it causes the system to obtain a rollback display of the web-based application and to store the display in a repository along with the new version number and the previous version of the web-based application.

[0111] Example 36 includes one of the themes from 21 to 35 and further specifies that the next version of the web-based application will be generated using a dedicated thread pool.

[0112] Example 37 includes one of the themes from Examples 21-36 and further specifies that the web-based application is a customized model.

[0113] Example 38 includes one of the themes from Examples 21-37, further defining the customized model as a language model.

[0114] Example 39 includes one of the subjects from Examples 21-38 and further specifies that the web-based application is managed.

Claims

1. In response to receiving an intention to roll back a web-based application, the system identifies a previous version of the web-based application that satisfies the rollback conditions, To generate the next version of the web-based application based on the previous version of the web-based application, A method comprising publishing the next version of the web-based application in order to complete the rollback of the web-based application.

2. To generate the next version of the aforementioned web-based application is: Extracting at least one code file from a first archive file associated with a previous version of the web-based application, The method according to claim 1, comprising updating the at least one code file with a new version number.

3. To generate the next version of the aforementioned web-based application is: The updated at least one code file is compressed into a second archive file, The process involves generating a digital signature based on the second archive file, The method of claim 2, further comprising generating the next version of the web-based application based on the second archive file and the digital signature.

4. Generating the aforementioned digital signature means The method according to claim 3, comprising processing the second archive file and private key associated with the web-based application through a signature algorithm to generate the digital signature.

5. The method according to any one of the prior claims, wherein the aforementioned prior version is associated with a first visibility parameter, and the rollback condition includes determining that the first visibility parameter matches a second visibility parameter associated with the current version of the web-based application.

6. The aforementioned rollback condition is the first rollback condition, The aforementioned method, The method according to any one of the prior claims, further comprising determining whether the current version of the web-based application satisfies a second rollback condition, which includes determining that the current version of the web-based application is not a rollback version.

7. The aforementioned rollback condition is the first rollback condition, The aforementioned method, The method according to any one of the prior claims, further comprising determining whether the current version of the web-based application satisfies a second rollback condition, which includes determining that the visibility parameter associated with the current version has not been changed to a hidden or inactive state.

8. The method according to any one of the prior claims, wherein generating the next version of the web-based application includes generating a new version number for the web-based application, the new version number being a number that causes a client device to recognize that the web-based application has been updated.

9. The method according to any one of the prior claims, wherein the rollback condition includes determining that the web-based application is missing an identified violation.

10. The method according to any one of the prior claims, further comprising providing a notification to the user interface that the rollback conditions are not met, in response to the determination that a previous version of the web-based application does not meet the rollback conditions.

11. To publish the following version of the aforementioned web-based application is to: The user interface provides version data related to the web-based application, The user interface receives confirmation of the version data, The method according to any one of the prior claims, further comprising publishing the next version of the web-based application based on the aforementioned confirmation.

12. The method according to claim 11, wherein the version data includes a new version number, a current version number associated with the current version of the web-based application, and a previous version number associated with the previous version.

13. Before publishing the next version of the web-based application, identify the current version of the web-based application, The method according to any one of the prior claims, further comprising: publishing the next version of the web-based application, and then archiving the current version of the web-based application in a repository by associating the current version with an archived state or an inactive state.

14. To obtain the display of the rollback in the aforementioned web-based application, The method according to any one of the prior claims, further comprising storing the aforementioned indication in a repository together with the new version number and the previous version of the web-based application.

15. The method according to any one of the prior claims, wherein the subsequent version of the web-based application is generated using a dedicated thread pool, and the web-based application is a customized model.

16. A computer-readable medium that, when executed by an electronic processor, stores instructions causing the electronic processor to perform the method according to any one of claims 1 to 15.

17. It is a system, Electronic processor, The system includes a memory, the memory being communicatively coupled to the electronic processor, and when executed by the electronic processor, the system Receiving the intention to roll back a web-based application from the user interface, Identifying a previous version of the web-based application that satisfies the rollback conditions, Based on the previous version of the web-based application, generate the next version of the web-based application, A system that stores instructions to publish the next version of the web-based application in order to complete the rollback of the web-based application.

18. When executed by the electronic processor, the instruction causing the system to generate the next version of the web-based application further enables the system to: Extracting at least one code file from a first archive file associated with a previous version of the web-based application, Updating at least one of the aforementioned code files with a new version number, The updated at least one code file is compressed into a second archive file, The process involves generating a digital signature based on the second archive file, The system according to claim 17, further comprising generating the next version of the web-based application based on the second archive file and the digital signature.

19. When executed by the electronic processor, the instruction causing the system to generate the digital signature further enables the system to: The system according to claim 18, which processes the second archive file and private key associated with the web-based application through a signature algorithm in order to generate the digital signature.

20. When executed by the electronic processor, the instruction causing the system to publish the next version of the web-based application further means that the system The user interface is provided with version data related to the web-based application, The user interface receives confirmation of the version data, Based on the aforementioned confirmation, the system according to any one of claims 17 to 19, which causes the system to publish the next version of the web-based application.