Automated Updates

    When software is sold as a one-time purchase, the customer can use that version of the software for life. Over time, the developer may implement bug fixes, make changes to support a newer OS or add minor or major enhancements.

    There are many ways to implement paid updates for a product purchase. The update process may involve the customer, the developer, features in the application, an activation server or online payment system.

    Automated Updates Automated Updates is a complete recipe of human and automated features to implement a flexible paid update process. This process only applies to a Product license, but never to a Trial or Subscription license. Here is a summary of the licensing tools required to support the recipe, how the process works and resources to understand and apply it to your Apps.

Requirements for Automated Updates

    QuickLicense Pro 10 on Mac or Windows implement features in the Automated Updates process. A license is applied with either a programming API call or the AddLicense wrapping tool. QuickLicense is often used with a companion plugin or library to apply licensing to various development environments.

    Automated Updates are supported by an API using QuickLicenseRT Linux 3.1, PluginXojoQLRT 3.1 and QLRT Xcode 4.1. Earlier versions of these tools do not implement Automated Updates.

    Minimum Requirements:

    • QuickLicense Pro 10
    • Safe Activation Service 3
    • Automated Updates

    Automated Updates require Safe Activation Service 3. Safe Activation can be used with a manual purchase process or integrated with many shopping carts or payment processors including Stripe, PayPal or Shopify to facilitate the update process.

    Automated Updates are not applicable to an Excel, Access or ExcelRT file wrapped into an App using AddLicense. That environment often uses a different update process that involves the Update button in the Open Data File Window.

    Other types of licensed applications using an API call or wrapping process should be compatible with Automated Updates. Contact Excel Software for questions regarding applicability on your specific project and runtime environment.

    Automated Updates require the active Ticket file be stored in the shared Ticket folder. An AddLicense wrapped application always uses this approach. When using the QuickLicense API approach, make sure the Location parameter for all licensing commands use the shared symbol.

Included Resources

    Automated Updates includes these resources:

    • Automated Updates Guide
    • Automated Updates Video
    • 1-Hour Technical Consulting
Click Here to Order

How Automated Updates Work

    The concept of Automated Updates described here does not specifically apply to any Excel Software product. Automated Updates describes a recipe that a third-party developer can apply to their specific QuickLicense protected application.

    When a customer buys a Product license, a Serial Number is delivered for activation. An Automated Updates expiration date of the form YYYYMMDD can be assigned to that Serial Number in Safe Activation. Typically, a customer is given a free period of Automated Updates with their original purchase. This simplifies many issues that might otherwise arise in a new customer purchase relationship.

    For example, if a bug is exposed unique to the customer environment or product usage, it usually occurs within the first few days or weeks of purchase. If a customer buys on Monday and a major release is announced on Tuesday, they may expect a free update. Developers do not want customers to delay purchases based on the next expected release date. Developers are constantly making bug fixes, plus minor and major enhancements so over time it is impossible to maintain a separate code base for each major release like 1.0, 2.0, etc.

    Software is built on a foundation of code outside of the developer’s control. That foundation may include the OS, the development IDE, Internet protocols, Server, independent products (MS Access, MS Excel, etc.) or libraries used by the App. Every piece of that foundational code evolves over time and each customer may have a slightly different mix. Every App must evolve to work within a changing environment, customer needs and expectations.

    Each product release is assigned a Build number of the form YYYYMMDD. The App may have a published version number such as 1.0 or 1.1 for marketing and communication purposes independent of the Build number. The same 1.1 version may be available in several build numbers such as 20240115, 20240129 and 20240301.

    An update process that allows a customer to confidently purchase on any date, optionally get a predefined period of free updates and then extend the Update period as desired works best for both developer and customers. Some customers will purchase and never buy or download updates. Others will periodically extend the Update expiration as needed or with auto-renew. Some customers may purchase several years of updates based on their budget, project or App type. Purchases may use a credit card, PO with bank wire or check payment or additional years of Updates could be offered with the original purchase.

    A Serial Number may license an App to one or multiple computers. The same Serial Number can license a family of products. A license can be securely moved between computers when an old computer is retired or the user switches from the office desktop to their laptop when traveling. A customer may need to reinstall older versions of a licensed App to retain compatibility with other Apps or their OS environment.

    These scenarios are all possible and greatly simplified with the Automated Updates process.