Understanding Releases and Notes

Our release notes contain detailed information about each release, including:

  • Improvements — new features and functionality added or updated in the product

  • Bug Fixes — bug fixes addressing previous functionality

  • UI Changes — changes to the user interface

  • API Changes — changes to the APIs (e.g. GraphQL) that may alter integrations

  • Configuration Changes — differences in the configurable settings

  • Upgrade Compatibility — basic release compatibility and advice for upgrades

Organization and Grouping

Release note entries are automatically structured according to their type (bug, feature, etc.) and their individual class (grouping), automatically sorted according to the priority of the entries, and marked up where appropriate to highlight entries that are more important or significant than others.

The two different groups are nested; first grouped by the issue type and then by class. For example, all bugs are listed together, and then groups of bugs related to the UI, or API, are grouped together.

The following types of release note, and their markup, are provided below:

  • Breaking Changes

  • Advanced Warning

  • Removed

  • Deprecation

  • Behavior Changes

  • Upgrades

  • Improvements, new features and functionality

  • Bug Fixes

  • Known Issues

  • Public Preview

  • Improvement

The following classes of release note entries are provided:

  • Removed

  • Upgrades

  • Behavior

  • Security

  • Installation and Deployment

  • Summary

  • Falcon Data Replicator

  • UI Changes

  • Documentation

  • Automation and Alerts

  • GraphQL API

  • Storage

  • API

  • Configuration

  • Dashboards and Widgets

  • Ingestion

  • Log Collector

  • Functions

  • Other

  • Packages

Deprecation, Removal, and Breaking Changes

On occasion, changes to LogScale may need to be made that remove features or that are are considered Breaking Changes. These indicate significant changes to the operation of LogScale that are required to support new functionality or behavior or to ensure the security or reliability of LogScale. These include:

  • Changes to the current behaviour of a feature. For example, changing the way a function operates

  • Changes to the errors, responses or reactions to certain functions. For example, raising an error in place or a warning

  • Changing the format or compatibility of a file or file format

  • Removal of a feature or function

When an item that fits these criteria has been identified:

  • If the item is a deprecation (i.e. planned removal of functionality) then an item will be added to the release notes identifying the deprecation.

  • If the item is a breaking change, a Pre Warning entry will be added to the release notes, indicating the feature or functionality will be altered.

  • These deprecating or pre-warnings will be repeated in each release note version until the item has been changed or removed.

  • The corresponding documentation page will be updated with a deprecation or pre-warning message to highlight the upcoming change.

  • There will be a delay of at least 12 weeks between notification of the upcoming change and it being applied.

  • Once the item has been removed, a Removal release note entry will be provided indicating the removal, impact, and alternatives (if available).

Version Numbering

We follow a version numbering convention that is similar to that recommended by Semantic Versioning. Basically, we use the MAJOR.MINOR.PATCH numbering format, which is defined as follows:

  • MAJOR: When there are major changes to the software, including high-profile ones, we'll change the value of this number, the primary number (e.g. the version will change from 1.x.x to 2.x.x).

  • MINOR: When we've added some new features or new functionality to LogScale software, we'll issue a new release and the secondary number will be changed (e.g., 1.16 to 1.18). Unlike Semantic Versioning, though, we allow backwards incompatible changes (e.g., changing compression algorithms).

  • PATCH: When a patch is added, the tertiary or third number will be increased (e.g., 1.18 to 1.18.1). Only backwards-compatible security or bug fixes are made with these. No new features or other code changes are permitted. This is important, as it means that each patch release should be more stable than the last.

Preview & Stable Releases

LogScale provides two separate releases:

  • Preview — includes new functionality that is still considered to be under development. Using a preview release gets you access to the newest features and functionality.

    Preview releases get deployed every seven days on Community Edition, and the same release is deployed to US and EU Cloud customers the week after.

  • Stable — contains the latest functionality and is considered appropriate for production use.

    LogScale on-premise customers are usually installing LogScale stable versions. These "on-prem" releases are provided at a slower pace than Cloud (preview) releases.

    We aim to make a Stable (on-prem) release once every six weeks that contains a roll-up of all preview features.

Release Summary, Support, and Upgrade Requirements

When reviewing the release notes, a section at the top of each release notes sections provides basic information about the release and upgrade compatibility. For example:

Version?Type?Release Date?Availability?End of Support







Req. Data






  • Version

    The full version number for this release.

  • Type

    The release type, either Stable or Preview.

  • Release Date

    The date when this version was released.

  • Availability

    Where the version will be available:

    • Cloud — available to our cloud customers

    • On-Prem — available to our On-Prem and cloud customers

  • End of Support

    The date when LogScale Support will no longer support this version.

    Due to the release structure, this may show Next Stable Version which indicates that support will exist until the next full Stable release type is made available.

  • Security Updates

    Indicates whether the release will continue to get security updates.

  • Upgrades From

    The minimum version of LogScale required to upgrade to this version. Upgrades from earlier versions may not succeed and are not recommended.


    For some releases, once upgraded to a the minimum upgrade release, it may not be possible to downgrade to a previous version. This will be shown in the corresponding release version when relevant.

  • Minimim JDK Version

    The compatible JDK version required to upgrade to this version.

  • Req. Data Migration

    If No, you can safely upgrade without worrying about migrating your data. If Yes data may need to be migrated, and changes will not be backwards comparible with previous versions. This will be in relation to the last stable version, not the minimum previous version. See Updating LogScale for more information on how to do this.

  • Config. Changes

    Indicates whether there are configuration changes within the release that should be checked and updated during the upgrade process to ensure that they meet your requirements.

Built-in Release Information

To determine the version of LogScale you are using and view information on the latest releases available from the LogScale user interface:

  1. Click the caption icon at the top of the screen: the Releases panel shows the full list of releases, with the most recent on top.

  2. Click any release link for all detailed information on that release.

Built-in Release Information

Figure 1. Built-in Release Information

If you're using LogScale Cloud, the latest — Preview or Stable — is used; upgrades are handled automatically for you.

Validating Release Checksums

The release notes include the checksum for release packages and docker images. You can verify the checksum for a package on the command-line.

To check an MD5 hash use the md5 tool:

$ md5 server-1.82.0.tar
MD5 (server-1.82.0.jar) = 4b4b4411d930d00275bc3a412c0c5c50

To check an SHA hash, use the shasum command:

$ shasum server-1.82.0.tar
ca22652ca303a162f81711f43977e14e528f6e85  server-1.82.0.tar

To check an SHA256 hash, use the shasum command:

$ shasum -a 256 server-1.82.0.tar
908a907b5c1ffbdce667b932daea0aab46a8ece4e164072f5bae0eb77d3bdd6f  server-1.82.0.tar

To check an SHA512 hash, use the shasum command:

$ shasum -a 512 server-1.82.0.tar
bbc65ea8641ac3d9910da4a9dcda0c1817d2a8acc2e81491a389d2671af7e57c12f019ad71af7309d4ad68b67997a6cbd3b0fba3a2048f07b7c7567abd05b8ae  server-1.82.0.tar

If the checksums do not match the quoted values, you should obtain a new version of the package.