Overview of Humio Releases

We’re very proud of the work we do at Humio: our Engineering division, composed of several departments, has been working hard to produce the latest release of Humio software. If you’re using the previous release and thinking of upgrading to the new one, you may want know about what has changed. You’ll find information on the sub-pages here — look for the links in the Release Notes section below.

If you’re using Humio Cloud, it uses the latest version; upgrades are handled for you. However, if you’re using a self-hosted version of Humio, this page describes our release methods. It also explains what our release version numbering is intended to convey, along with providing other information to assist you in deciding how to update your installation.

Preview & Stable Releases

Humio is always eager to publish new releases to make new features available quickly. However, this could sometimes result in some instability. Knowing some clients don’t want instability, we distinguish releases based on whether they are a preview or a stable release. This can help you to decide a strategy for upgrading.

Many administrators will download the latest preview release and install it on a test server or a non-production system. This gives them a chance to try new features and to see if they will need to make any adjustments to their systems or their metrics. Then, when the stable release is available, they’re ready to upgrade their production systems with it.

As features are developed, an odd-numbered release (e.g., 1.17, not 1.18) will be available containing the new features. While such a release is intended to be usable, there is a chance that problems could arise. Once the features have been tested sufficiently, the stable release will be made available. So, we recommend you use the preview release for testing, but wait for the stable release to deploy it on production systems.

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 Humio 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, unrelated code changes are permitted. This is important, as it means that each patch release should be more stable than the last. Incidentally, preview releases will often include patches. We don’t want to make you wait for a patch if we have it ready.

Release Notes

To reiterate, the numbering convention we follow for releases is fairly common and simple: an odd-numbered release is intended to be a preview to the stable release that will follow it; and an even-numbered release is a stable release. For example, when 1.17 was released, it was a preview of stable release 1.18.

More meticulous administrators will review the details of each release before upgrading. However, reviewing these notes can sometimes be important to any administrator. For instance, you may need to migrate some data, or there may be some sort of conflict with your systems. To be sure, you should at least glance at the release notes.

Below are links to the notes for the latest releases, as well as an archive of older ones:

  • Stable Releases — The latest stable release is 1.18.0

  • Preview Releases — The latest preview release is 1.17.0

  • Archive — As a reference, we keep the notes for older releases, ones that were created before the current versioning scheme was adopted.

Upgrade Requirements

When reviewing the release notes, you’ll see some text at the top. It will state the release date and two primary warnings. Below are descriptions of those warnings:

  • Minimum Previous Humio Version
    This field states the minimum version of Humio required from which to upgrade. If you try to upgrade from a much earlier version, there’s a possibility that you will have problems.

  • Requires Data Migrations
    If this field has a value of false, you can safely upgrade without worrying about migrating your data. If it says it’s true, though, you will have to migrate data. This will be in relation to the last stable version, not the minimum previous version. So be prepared. See our documentation on Data Migrations to learn more on how to do this.